FW 6.83 für 6490 und Synology neues Problem

[rstle]

Nachdem nun endlich für die Kabelboxen die FW 6.83 gelandet ist,
habe ich nun ein Problem mit dem Systemruhezustand des Synology Servers.
Bis 6.63 ging die Kiste (nach Abmeldung) immer in System Hibernation (= blau atmend).
Seit 6.83 komme ich nur noch in den HDD Deep Sleep (= grün atmend).
Habe in der 6490 alles durchgesehen, finde aber keinen Grund.
Zum Test ist nur noch die FB mit dem Server verbunden, kein weiteres Gerät.
Ich könnte zwar wieder auf FW 6.63 zurückgehen, aber dann lahmt das Menü wieder unsäglich.
Hat jemand ähnliche Erfahrungen gemacht ?

 

[enno25]

Ursache könnte ipv6 sein, schalte doch Mal testweise das IPv6 Interface der Diskstation ab.

 

[rstle]

Danke,
Ich hab IPv6 mal abgeschaltet, aber unter 6.63 funktionierte es auch mit.
Muß jetzt nur noch etwas warten, bis die Kiste umschaltet,
will wegen der Fehlersuche nichts daran ändern.
Ich melde mich dann nochmals

- - - Aktualisiert - - -

Das wars wohl doch nicht.
Es grünt so grün...

 

[jackzone]

Hi,

ich habe mit meiner 7390 und der DS213+ gleiches Problem. Vor dem Update auf 6.83 (von 6.51) ging die DS nach voreingestellter Zeit brav in den Systemruhezustand (blau pulsierende LED), jetzt erreicht die DS lediglich den HDD-Ruhezustand (grün pulsierende LED).

Hatte diesbzgl. auch schon Kontakt mit dem AVM-Support aufgenommen, aber laut meinen LOGs verwende ich nicht unterstütze Funktionen in meiner 7390 (vermute das einst eingeschaltete Telnet) und daher könnte man mir so nicht weiterhelfen. Ich sollte doch bitte recovern, keine Settingssicherung einspielen und mich wieder melden, wenn das Problem dann weiterhin bestehen sollte.

Am meisten ärgere ich mich über mich selbst: bei dem Update von 6.51 auf 6.83 habe ich die Update-Suche und direkte Installation des Fritz!OS verwendet und dabei die Sicherung meiner Einstellungen vergessen (hatte bis dato immer über die Fritz!OS-Datei aktualisiert und da wird zuerst gesichert) - jetzt kann ich nicht mal eben zurück!

Ich konnte bisher leider auch keine Lösung für das o. g. Problem finden.

Gruß
jackzone

 

[PeterPawn]

Da sind aber nicht etwa die NAS-Geräte mit der FRITZ!Box über WLAN verbunden, wenn die nicht richtig schlafen gehen wollen?

 

[effmue]

Guude,
meine (alten) Synos gehen problemfrei in den Ruhezustand. (wohl weil sie kein WOL unterstützen..)
Bitte checke mal ob du evtl. in der "Heimnetzübersicht-->Netzwerkverbindungen" beim betroffenen NAS einen Haken bei WoL "...automatisch starten, sobald..." gesetzt hast.

 

[rstle]

Das Problem dürfte wohl an beiden Geräten liegen.
Definitiv liegt es am Medienserver der DS, wenn der gestartet ist, (aber nur unter FB FW 6.83) geht die DS nicht mehr in Tiefschlaf.
Dummerweise kann ich nicht mehr genau nachvollziehen ab wann das Problem auftrat,
da ich relativ zeitnah beide Geräte aktualisiert habe
und da im Keller installiert, nicht nachgesehen habe, was da nach welchem Update so nicht mehr richtig spielt.
Definitiv bis Anfang Mai war die DS aber noch i.O.
also vor deren letzten Updates der DS (Medienserver und 2x System) und mit FW 6.63 der FB.
Dafür reicht einmaliges Starten der DS von einem Rechner aus.
Danach können sämtliche LAN-Geräte abgemeldet und (Ausnahme Fritzbox) abgesteckt werden,
die Kiste will nicht mehr schlafen. Ziehe ich dann auch noch die FB raus, kehrt Ruhe ein,
neues anstecken der Box läßt die DS aber im Tiefschlaf.
WOL und WLAN nicht aktiv, sonst würde die DS da auch sofort wieder anspringen.
Ist Pest oder Cholera. FW 6.63 entfällt, weil Oberfläche inakzeptabel lahmt.
U.A. deshalb hat ja AVM auch die 6.83 rausgebracht, obwohl vorher Stein und Bein behauptet,
es läge an meiner Konfig. Komisch nur, daß die gleiche Konfig nach dem Update auf 6.83 nun wieselflink ist.
Der Grund dafür ist ja hier auch hinlänglich bekannt.
Bei Syno hab ich ein Ticket aufgemacht, bei AVM könnte ich auch, verwende ja keine "nicht unterstützten Funktionen".
Nur nach den letzten AVM Antworten - siehe Trägheit - sehe ich da wenig Hoffnung.

 

[jackzone]

Auch bei mir sind WOL und WLAN nicht aktiv. Wenn ich das LAN-Kabel an der DS abziehe, wechselt sie in den Systemruhezustand, wieder eingesteckt bleibt sie weiterhin im Tiefschlafmodus.

Wenn ich dich, rstle richtig verstanden habe, geht die DS mit der Fritz!OS 6.83 in Tiefschlaf, wenn man den Medienserver deaktivert? Das werde ich nachher mal ausprobieren, auch wenn der Systemruhezustand mit 6.51 und aktiviertem Medienserver problemlos funktionierte. Ist zwar keine Lösung für mich, da ich den Medienserver benötige, aber evtl. könnte diese Info dem AVM-Support helfen.

Gruß, jackzone

 

[rstle]

Medienserver stoppen und es wird wieder blau. Ist aber keine Lösung, denn ich brauche den Server auch.
Ansonsten alles exakt so wie bei mir.
Allerdings muß die DS nach dem Stopp des Medienservers neu gestartet werden sonst bleibts bei grün.

Habe Herrn Fritz mit einem Ticket belästigt, die 6.83 hat ja noch andere Fehler wie Paketmitschnitt etc.
War wohl doch ein Schnellschuß, Hauptsache noch mehr Funktionen rein, die nur die wenigsten Nutzer wirklich brauchen.
Ich hab da lieber weniger, aber dafür funktionierend.

 

[Ilja13]

Seit 6.83 erkennt die FB Medienserver an den angeschlossenen Geräten. So taucht bei jedem Windows-PC neben dem Computernamen auch "Windows Media Server" in der Netzwerkübersicht.
Mich persönlich nervt das, da der WMS eigentlich deaktiviert wurde. Durch ein Windowsupdate wurde dieser durch das Update-Tool kurz gestartet (Funktion testen?) du wieder beendet. Danach war in der FB dieser Vermerk aufgetaucht und geht nicht mehr weg!

Evtl. versucht die FB ständig den Mediaserver anzupingen, was den Ruhezustand verhindert?

 

[rstle]

So was in der Art vermute ich auch. Aber warum daß? War ja mit 6.63 auch nicht.
Offenbar will die FB jetzt länger Unterhaltung pflegen.
Paketmitschnitte funktionieren ja auch nicht mehr zwecks Analyse was die da so quasseln.
Warten wir mal ab was Herr Fritz mir antwortet. Kam nämlich erfreulicherweise nach sehr kurzer Zeit schon Antwort, sehr lobenswert.
Habe gerade ausführlichst zurückgeschrieben, gleich noch mein Lieblingsthema
MAC Anzeige im Netzwerkfenster wieder standardmäßig.
Haben sich ja einige wenige Massen dafür ausgesprochen in meiner Umfrage.
Und gleich noch alle anderen Macken dazu geschrieben, spart Tickets und bringt auch nichts.
Da ich kein Windows mehr habe, nur noch Macs, kann ich da nicht mitreden.

 

[PeterPawn]

Zumindest macht die FRITZ!Box ein "SUBSCRIBE" für Events (z.B. von allem, was sich als "Media Renderer" outet) und wenn das von dem jeweiligen Server schon als "Da will ein Client was von mir." interpretiert wird, kommt der vielleicht nicht mehr bis zum Ruhezustand.

Ein regelmäßiger Kontakt sollte eher nicht das Problem sein oder es sind ganz schön lange Timeouts beim NAS eingestellt - irgendwelche Broadcasts muß so ein Gerät ja ohnehin ignorieren, wenn es nicht alle Nase lang ein Sleep-Timeout wieder zurücksetzen will, denn die treten stets und ständig auf.

Diese Subscriptions startet die Box dann auch mit einem Header "TIMEOUT: Second-infinite" und jetzt liegt es am Mediaserver, was der in seiner Antwort seinerseits als TIMEOUT-Header sendet - nach dessen Ablauf wird die Box i.d.R. eine neue Registrierung senden und wenn der Server dann noch wach sein sollte, könnte er das (es ist ja Unicast-Traffic) durchaus auch als Abbruch des Sleep-Timeouts werten.

Was der (Media-)Server da seinerseits antwortet, findet man am einfachsten mit einem Mitschnitt heraus und dann muß man halt dafür sorgen, daß dieses Subscription-Timeout größer ist als das Sleep-Timeout. Kriegt man das hin, sollte das NAS auch wieder schlafen gehen können und dann ohne WoL ja auch nicht wieder spontan aufwachen.

Wenn das hier schon auf den Media-Server heruntergebrochen wurde, dann kommen ja wohl andere Dienste nicht mehr in Frage ... wobei die Box eben auch regelmäßig versucht (zumindest solange eine Seite offen ist, wo das eine Rolle spielt), ob ein LAN-Client auf Port 80 einen Service bereitstellt und dann aus dem Namen in der Netzwerkanzeige im GUI einen HTTP-Link machen möchte, wenn so ein Service gefunden wurde.

 

[rstle]

Mediaserver ist in Verbindung mit der FW 6.83 meine Vermutung, nicht Wissen.
Ich würde ja gerne mal einen Paketmitschnitt machen, aber das kann die 6.83 ja auch nicht mehr.
Wobei, spontanes Aufwachen habe ich nicht zu beklagen.
Wenn sie denn mal schlafen gegangen ist, dann bleibt sie bis zum gewollten Weckruf.
Warum Herr Fritz da wieder gebastelt hat.
Ich tendiere eher zu never touch... wenn was läuft.
Warten wir mal die Antwort von Herrn Fritz ab.

 

[megakeule]

Du hast doch auf der Syno ein komplettes (und zugängliche) Linux zur Verfügung. Mach den Paketmitschnitt doch einfach dort mit Bordmitteln.

 

[rstle]

Da wird sich Herr Fritz aber bedanken.
Ich warte jetzt erstmal was so zurück kommt.

 

[PeterPawn]

[...] aber laut meinen LOGs verwende ich nicht unterstütze Funktionen in meiner 7390 (vermute das einst eingeschaltete Telnet) und daher könnte man mir so nicht weiterhelfen. Ich sollte doch bitte recovern, keine Settingssicherung einspielen und mich wieder melden, wenn das Problem dann weiterhin bestehen sollte.

Ich kann zwar die Beweggründe dahinter in Grenzen verstehen ... aber ich habe auch zu oft selbst erlebt, daß dieses Argument mit dem "beschmutzten System" vom Support nur als bequemer Weg zum "Abbügeln" genutzt wurde, weil wohl kein Kunde freiwillig bei einem kleineren Problem seine Box erst einmal mit Recovery-Programmen bearbeiten will - und bei anderen Modellen hat er dazu gar nicht erst die Chance (Stichwort DOCSIS - wobei das ja nun eigentlich auch vollkommen egal wäre, da sich ja inzwischen auch herumgesprochen hat, wie man über den Bootloader in diesen Modellen die Firmware aktualisieren kann).

Zumindest für die VR9-Modelle mit ext2-Unterstützung für das Root-Filesystem ist das aber wieder Kinderkram, dieses "tainted"-Flag zu löschen - auch wenn man keinen Shell-Zugang hat. Für diesen Zweck habe ich in meinem GitHub-Repository mal ein "build_reset_tainted_image" hinzugefügt und im "first-aid"-Verzeichnis die Images für 7490 und 7412. Einfach in die Box laden lassen und einmalig damit starten ... danach sollte die AVM-Anzeige für "Vom Hersteller nicht unterstützte Änderungen" Geschichte sein und auch in den Support-Daten nicht mehr auftauchen.

Für die 7390 müßte man das etwas anders angehen, die kennt kein "ext2" als rootfs (siehe arch/mips/fusiv/fusiv_mips32/fusiv_mtd.c) und man muß ein passendes SquashFS-Image anstelle des ext2-Images erstellen, was wieder zusätzliche Binärdateien braucht (mksquashfs). Ansonsten bleibt das Prinzip genau dasselbe ...

 

[jackzone]

Danke für diese Info.

Mir ist übrigens noch etwas aufgefallen, seit ich die 6.83 eingespielt habe: meine 7390 hat in unregelmäßigen Abständen Aussetzer (bis zu einer Minute) und ist per Weboberfläche nicht erreichbar. Zudem finden sich immer wieder folgende Einträge in der Ereignisanzeige:

Der bekannte Powerline-Adapter wurde verbunden. [87 Meldungen seit 26.05.17 23:20:11]

Ich konnte in anderen Foren ähnliche Meldungen beobachten. Mit der 6.51 gab es diese Aussetzer nicht.

 

[Shirocco88]

Zurücksetzen des Node-87 durch Recovery

Stichwort DOCSIS - wobei das ja nun eigentlich auch vollkommen egal wäre, da sich ja inzwischen auch herumgesprochen hat, wie man über den Bootloader in diesen Modellen die Firmware aktualisieren kann
...
Für die 7390 müßte man das etwas anders angehen, die kennt kein "ext2" als rootfs (siehe arch/mips/fusiv/fusiv_mips32/fusiv_mtd.c) und man muß ein passendes SquashFS-Image anstelle des ext2-Images erstellen, was wieder zusätzliche Binärdateien braucht (mksquashfs). Ansonsten bleibt das Prinzip genau dasselbe ...

IMHO: das Zurücksetzen des Node-87 sollte auch mit "Recovery Simulation" möglich sein,
d.h. TFFS-Dump aus den erweiterten Supportdaten mittels "tffs_from_supportdata", "dissect_tffs_dump" zerlegen,
den Node-87 "zurücksetzen" und neues tffs erstellen "build_tffs_image" und flashen "eva_store_tffs".


Quelle:

aus den erweiterten Support-Daten einen TFFS-Dump extrahieren (schauen, welcher der aktuellere ist) und dann mit diversen Skript-Dateien dieses TFFS in seine Bestandteile zerlegen, die Dateien für den Node 87 identifizieren und mit anderen Skriptdateien (die brauchen dann aber alle zusätzlichen Nodes als Parameterliste, eine Version mit einer Liste der "normalen Nodes" als Datei gibt es dort bisher nicht) dann wieder ein TFFS zusammenbauen und dieses anschließend über den Bootloader in beide Partitionen schreiben

 

[PeterPawn]

@Shirocco88:
Das stimmt ... aber der Aufwand wäre eben doch wesentlich höher (zumindest der zeitliche) und den Zugriff über den Bootloader bräuchte man am Ende genauso bei beiden Lösungen und auch die Notwendigkeit einer Linux-Installation ist in beiden Fällen vorhanden - egal, ob man (zumindest mit meinen Skripten) das TFFS-Image ändert oder ob man sich ein Boot-Image baut.

Wenn ich mal lustig bin, baue ich auch noch die Unterstützung von SquashFS-Images in diese "build_irgendwas"-Skripte in "toolbox" ein ... 7580/7560 und wohl auch die 7590 bräuchten das ohnehin (von den neueren Modellen), denn da wird in "drivers/mtd/avm/partparse.c" praktisch nur auf SquashFS-Signaturen getestet (die kennen also kein anderes Format).

Wenn man da etwas anderes verwenden wollte, müßte man wohl auf eine "initrd" zurückgreifen - zumindest ist mal bei der 7580 "CONFIG_BLK_DEV_INITRD=y" gesetzt. Wobei ich nicht weiß, ob EVA ohne passenden "mtdram1"-Parameter überhaupt ein System im RAM starten würde - aber man sollte über "rd_start" und "rd_size" als Kernel-Parameter zunächst mal eine "initrd" einbinden können und notfalls legt man (einen Versuch ist es allemal wert) einfach "mtdram1" auf ein "kernel-only area", wenn man das alles bereits in der "initrd" abhandeln will. Wobei das bei der 7390 wohl auch wieder nicht paßt, da dürfte der AVM-Kernel gar keine "initrd" berücksichtigen, wenn man der AVM-Konfiguration im OpenSource-Paket glaubt - daher ist dann das SquashFS doch wieder der gemeinsame Nenner, mit dem man die meisten Modelle erreichen sollte.

Bei Puma6 sieht das dann wieder etwas anders aus ... mal schauen, wann's die Kernel-Quellen gibt - am Ende sollte es mit einem leicht geändertem "eva_to_memory" da aber genauso funktionieren.

 

[jackzone]

Da wird sich Herr Fritz aber bedanken.
Ich warte jetzt erstmal was so zurück kommt.

Hallo zusammen,

hat sich AVM inzwischen zu dem Problem geäußert?

VG jackzone