internal disk woke up from hibernation
- Ersteller ratz
- Erstellt am
-
Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.
Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.
Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier
- Status
Hallo ratz,
ich habe die DS213+ seit fast 2 Jahren, und das Aufwach-Problem bisher nicht in den Griff bekommen. Ich hatte auch in den Logs nichts Erhellendes gefunden (hatte eine Weile sogar einen syslog Server auf einem Rechner laufen, an den die DS ihre Logs geschickt hat).
Du schreibst, Du hast es tatsächlich geschafft, dass die DS die Nacht durchschläft, bis zum nächsten Logon. Das macht mir Mut, dass das wohl tatsächlich möglich ist. Ich nehme einen neuen Anlauf!
Kurze Beschreibung des Setups:
DS213+ mit neuester Firmware (derzeit 5.0-4493 Update 3 vom 19.07.2014)
FritzBox 7390 mit neuester Firmware (06.04) am Telekom-DSL-Anschluss, Portfreigaben zur DS siehe unten
An der Fritzbox hängt:
- DS213+
- bis zu 2 Rechner per LAN-Kabel (diese sind aber meistens ausgeschaltet)
- eine ältere Fritzbox als WLAN-Router (dahinter iPads, iPhones, Androiden, TV mit DLNS)
ABER:
M.E. können wir alle Geräte außer Fritzbox und DS213+ bei der Betrachtung außen vor lassen, weil die DS aufwacht, auch wenn diese ausgeschaltet sind.
Zur Kontrolle gehe ich dann von außen auf die Fritzbox und kann dies überprüfen.
Symptom:
Die Meldung "Internal disks woke up from hibernation" kommt typischerweise ca. alle 30 bis 120 Minuten (ganz selten mal länger, bei Durchsicht habe ich einige wenige nächtliche Aufwacher mit 3 Stunden Abstand gefunden). Auch nachts, wenn im Heimnetz kein Gerät eingeschaltet ist!
Auffallend ist auch, dass nach 10 bis 60 Minuten, nachdem die DS per Timer um Mitternacht heruntergefahren wurde (im Log "Windows file service was stopped.") sie wieder hochfährt ("System started to boot up." gefolgt von "Windows file service was started."), obwohl kein weiteres Gerät im Heimnetz eingeschaltet ist.
Applikationen auf der DS:
Auf der DS läuft Photostation. Zugriffe aus dem Internet sind aber in den allermeisten Fällen nicht die Ursache für das Aufwachen (tief nachts, außerdem im PhotoStation Log kontrollierbar).
Daneben noch der Medienserver, aber der TV mit DNLS läuft nachts natürlich auch nicht.
Zu den Portfreigaben ... Die sind recht großzügig für den Zugriff von außen:
Bezeichnung Protokoll Port an Port
NAS DSM TCP 5001 5001
NAS http TCP 80 80
NAS WebDAV TCP 5005-5006 5005-5006
NAS File Station TCP 7001 7001
NAS DSM ungesichert TCP 5000 5000
NAS https TCP 443 443
WOL UDP 9 9
(Anm. zum TCP 5000: Den brauche ich, weil ich sonst aus meinem Firmennetzwerk nicht per https und Port 5001 drauf komme.)
WOL in der Fritzbox ist aktiviert, für die PhotoStation-Zugriff von außen. Das Problem bestand m.W. jedoch bereits vor der WOL-Aktivierung.
Die Fritzbox 7390 wird von der DS als UPnP-Router gefunden (gerade getestet). Jedoch nutze ich nicht die Routerkonfiguration von der DS aus, das mache ich in der Fritzbox selbst.
Weitere evtl. relevante Einstellungen in der DS:
Keine USB-Geräte angeschlossen
Manuelle IP-Adresse
"Windows-Netzwerkerkennung aktivieren" ist aktiv (Netzwerk -> DSM-Einstellungen)
"WOL on LAN1 1 aktivieren" ist aktiv
Energie-Zeitplan: Täglich herunterfahren um 23:59, hochfahren um 9:00
Ruhezustand: Interne Platten in Ruhezustand nach 30 Minuten Inaktivität
"Systemruhezustand 60 Sekunden nach HDD Ruhezustand aktivieren" und "Broadcasting Pakete von Windows Explorer ignorieren" sind beide aktiviert
Das müssten die wichtigsten Informationen sein, hoffe ich.
Hast Du einen Tip, wo ich anfangen soll? Ohne konkrete Verdachtsmomente würde ich zunächst alle Portfreigaben schließen sowie WOL deaktivieren und beobachten, ob sich das Verhalten bessert. Dankbar wäre ich aber für einen konkreten Tipp!
Danke und Grüße
Cruiser07
ich habe die DS213+ seit fast 2 Jahren, und das Aufwach-Problem bisher nicht in den Griff bekommen. Ich hatte auch in den Logs nichts Erhellendes gefunden (hatte eine Weile sogar einen syslog Server auf einem Rechner laufen, an den die DS ihre Logs geschickt hat).
Du schreibst, Du hast es tatsächlich geschafft, dass die DS die Nacht durchschläft, bis zum nächsten Logon. Das macht mir Mut, dass das wohl tatsächlich möglich ist. Ich nehme einen neuen Anlauf!
Kurze Beschreibung des Setups:
DS213+ mit neuester Firmware (derzeit 5.0-4493 Update 3 vom 19.07.2014)
FritzBox 7390 mit neuester Firmware (06.04) am Telekom-DSL-Anschluss, Portfreigaben zur DS siehe unten
An der Fritzbox hängt:
- DS213+
- bis zu 2 Rechner per LAN-Kabel (diese sind aber meistens ausgeschaltet)
- eine ältere Fritzbox als WLAN-Router (dahinter iPads, iPhones, Androiden, TV mit DLNS)
ABER:
M.E. können wir alle Geräte außer Fritzbox und DS213+ bei der Betrachtung außen vor lassen, weil die DS aufwacht, auch wenn diese ausgeschaltet sind.
Zur Kontrolle gehe ich dann von außen auf die Fritzbox und kann dies überprüfen.
Symptom:
Die Meldung "Internal disks woke up from hibernation" kommt typischerweise ca. alle 30 bis 120 Minuten (ganz selten mal länger, bei Durchsicht habe ich einige wenige nächtliche Aufwacher mit 3 Stunden Abstand gefunden). Auch nachts, wenn im Heimnetz kein Gerät eingeschaltet ist!
Auffallend ist auch, dass nach 10 bis 60 Minuten, nachdem die DS per Timer um Mitternacht heruntergefahren wurde (im Log "Windows file service was stopped.") sie wieder hochfährt ("System started to boot up." gefolgt von "Windows file service was started."), obwohl kein weiteres Gerät im Heimnetz eingeschaltet ist.
Applikationen auf der DS:
Auf der DS läuft Photostation. Zugriffe aus dem Internet sind aber in den allermeisten Fällen nicht die Ursache für das Aufwachen (tief nachts, außerdem im PhotoStation Log kontrollierbar).
Daneben noch der Medienserver, aber der TV mit DNLS läuft nachts natürlich auch nicht.
Zu den Portfreigaben ... Die sind recht großzügig für den Zugriff von außen:
Bezeichnung Protokoll Port an Port
NAS DSM TCP 5001 5001
NAS http TCP 80 80
NAS WebDAV TCP 5005-5006 5005-5006
NAS File Station TCP 7001 7001
NAS DSM ungesichert TCP 5000 5000
NAS https TCP 443 443
WOL UDP 9 9
(Anm. zum TCP 5000: Den brauche ich, weil ich sonst aus meinem Firmennetzwerk nicht per https und Port 5001 drauf komme.)
WOL in der Fritzbox ist aktiviert, für die PhotoStation-Zugriff von außen. Das Problem bestand m.W. jedoch bereits vor der WOL-Aktivierung.
Die Fritzbox 7390 wird von der DS als UPnP-Router gefunden (gerade getestet). Jedoch nutze ich nicht die Routerkonfiguration von der DS aus, das mache ich in der Fritzbox selbst.
Weitere evtl. relevante Einstellungen in der DS:
Keine USB-Geräte angeschlossen
Manuelle IP-Adresse
"Windows-Netzwerkerkennung aktivieren" ist aktiv (Netzwerk -> DSM-Einstellungen)
"WOL on LAN1 1 aktivieren" ist aktiv
Energie-Zeitplan: Täglich herunterfahren um 23:59, hochfahren um 9:00
Ruhezustand: Interne Platten in Ruhezustand nach 30 Minuten Inaktivität
"Systemruhezustand 60 Sekunden nach HDD Ruhezustand aktivieren" und "Broadcasting Pakete von Windows Explorer ignorieren" sind beide aktiviert
Das müssten die wichtigsten Informationen sein, hoffe ich.
Hast Du einen Tip, wo ich anfangen soll? Ohne konkrete Verdachtsmomente würde ich zunächst alle Portfreigaben schließen sowie WOL deaktivieren und beobachten, ob sich das Verhalten bessert. Dankbar wäre ich aber für einen konkreten Tipp!
Danke und Grüße
Cruiser07
Nein, noch nicht - aber jetzt! Ist das ein bekannter "Aufwecker"?? Das wäre ja zu einfach ;-)
Ja, ist es. ;-)
Es muss jetzt nicht die Musterlösung sein, aber vielleicht liegt es ja genau daran.
Es muss jetzt nicht die Musterlösung sein, aber vielleicht liegt es ja genau daran.
Hm, da wäre ja einfach.
Allerdings kann ich mir nicht vorstellen, dass die DS nach dem kompletten Herunterfahren (siehe Beschreibung: zeitgesteuert von 23:59 bis 09:00 Uhr) extra wieder hochfährt, um die Zeit zu synchronisieren ...
Kann natürlich gut sein, dass das Hochfahren der Festplatten (und der DS aus Systemruhezustand) eine andere Ursache hat als das komplette Hochfahren der DS nach zeitgesteuertem Herunterfahren.
Mein Bauchgefühl sagt mir, dass irgendwelche Netzwerkpakete die DS aufwecken und ich um ein Netzwerksniffing nicht herumkomme. Wenn's einfacher ist lasse ich mich positiv überraschen ;-)
Allerdings kann ich mir nicht vorstellen, dass die DS nach dem kompletten Herunterfahren (siehe Beschreibung: zeitgesteuert von 23:59 bis 09:00 Uhr) extra wieder hochfährt, um die Zeit zu synchronisieren ...
Kann natürlich gut sein, dass das Hochfahren der Festplatten (und der DS aus Systemruhezustand) eine andere Ursache hat als das komplette Hochfahren der DS nach zeitgesteuertem Herunterfahren.
Mein Bauchgefühl sagt mir, dass irgendwelche Netzwerkpakete die DS aufwecken und ich um ein Netzwerksniffing nicht herumkomme. Wenn's einfacher ist lasse ich mich positiv überraschen ;-)
Hallo,
ich sehe es genau so wie Matthieu, Port 80 und 443 wird regelmäßig von Scripten abgegrast und die WOL Einstellung in der Fritzbox erledigt dann den Rest in der abgeschalteten Zeit.
Gruß Götz
ich sehe es genau so wie Matthieu, Port 80 und 443 wird regelmäßig von Scripten abgegrast und die WOL Einstellung in der Fritzbox erledigt dann den Rest in der abgeschalteten Zeit.
Gruß Götz
Port 80 habe ich bisher für Internet-Zugriff auf die PhotoStation offen. Die PhotoStation-Links für die User könnte ich zwar auf 443 (https) ändern, jedoch ist die PhotoStation aus Firmennetzwerken über https oft nicht erreichbar. Dann bekommen diese User eine Fehlermeldung - schlecht.
Ich habe heute das NetworkSniffing der Fritzbox einige Stunden mitlaufen lassen. Bisher ist mir nicht ganz klar, ob eth0 oder lan hier die interessante Netzwerkschnittstelle ist, oder beide?
Ich habe eben mal mit WireShark einen Blick auf das eth File der lan-Schnittstelle geworfen.
Während der Sniffing-Zeit gab es drei mal die Meldung "Internal disks woke up from hibernation".
Ich habe versucht, eine Besonderheit im Network-Traffic zur DS um diese Zeitpunkte herum zu erkennen, aber bisher ist mir das nicht gelungen. Es ist aber auch das erste Mal, dass ich mich in die Tiefen des Network Sniffings begebe.
Bange kann da einem schon werden, wenn man sieht, welche IP-Adressen da mit der DS kommunizieren. Wenn ich die mit WHOIS auflöse, dann tauchen da China Telecom auf, und eine türkische Doga Telekom.
Ich werde nun mal den Fritzbox-Sniffer über Nacht mitlaufen lassen. Da hoffe ich auf insgesamt weniger Traffic, und hoffentlich erkennt man da eher verdächtige Zugriffe. Insbesondere wenn die DS aus dem komplett heruntergefahrenen Zustand aufwacht - der Aufwecker muss doch über das LAN-Kabel kommen!
Dagegen könnte das Aufwachen der Festplatten natürlich auch DS-intern verursacht sein, und ich kann networksniffen, so lange ich will ...
Aber ich habe Blut geleckt, und werde so schnell nicht aufgeben!
Cruiser07
Ich habe heute das NetworkSniffing der Fritzbox einige Stunden mitlaufen lassen. Bisher ist mir nicht ganz klar, ob eth0 oder lan hier die interessante Netzwerkschnittstelle ist, oder beide?
Ich habe eben mal mit WireShark einen Blick auf das eth File der lan-Schnittstelle geworfen.
Während der Sniffing-Zeit gab es drei mal die Meldung "Internal disks woke up from hibernation".
Ich habe versucht, eine Besonderheit im Network-Traffic zur DS um diese Zeitpunkte herum zu erkennen, aber bisher ist mir das nicht gelungen. Es ist aber auch das erste Mal, dass ich mich in die Tiefen des Network Sniffings begebe.
Bange kann da einem schon werden, wenn man sieht, welche IP-Adressen da mit der DS kommunizieren. Wenn ich die mit WHOIS auflöse, dann tauchen da China Telecom auf, und eine türkische Doga Telekom.
Ich werde nun mal den Fritzbox-Sniffer über Nacht mitlaufen lassen. Da hoffe ich auf insgesamt weniger Traffic, und hoffentlich erkennt man da eher verdächtige Zugriffe. Insbesondere wenn die DS aus dem komplett heruntergefahrenen Zustand aufwacht - der Aufwecker muss doch über das LAN-Kabel kommen!
Dagegen könnte das Aufwachen der Festplatten natürlich auch DS-intern verursacht sein, und ich kann networksniffen, so lange ich will ...
Aber ich habe Blut geleckt, und werde so schnell nicht aufgeben!
Cruiser07
Die Ursache für das Aufwecken der runtergefahrenen DS habe ich nun im Network-Traffic gefunden. Diesmal geschah es 22 Minuten nach dem Herunterfahren.
Es gibt ARP-Broadcasts "Who has 192.168.1.31? Tell 192.168.1.1":
1370 22:21:20.399088 24:65:11:6c:70:34 Broadcast ARP 42 Who has 192.168.1.31? Tell 192.168.1.1
192.168.1.31 ist die DS, 192.168.1.1 die Fritzbox 7390.
2 Sekunden später sehe ist das MagicPacket mit dem WOL Protokoll.
Broacdcast ARP und WOL kommen noch ein paar Mal, bis sich die DS mit einem IGMPv3 Paket meldet - aber an Zieladdresse 224.0.0.22 (siehe http://en.wikipedia.org/wiki/Multicast_address):
3129 22:22:32.020750 192.168.1.31 224.0.0.22 IGMPv3 60 Membership Report / Join group 224.0.0.251 for any sources
Warum gibt es den ARP-Broadcasts "Who has 192.168.1.31? Tell 192.168.1.1"?
3s vor diesem ARP wurden von dem internen WLAN-Router (alte Fritzbox, an der momentan ein iPad angemeldet ist) 192.168.1.29 mehrere SSDP-Pakete geschickt, an 239.255.255.250:1900. Siehe http://de.wikipedia.org/wiki/Simple_Service_Discovery_Protocol: "... ist ein Netzwerkprotokoll, welches zur Suche nach UPnP-Geräten im Netzwerk dient."
Hier scheint wohl das iPad am internen Router eine UPnP-Suche zu machen, die dann den ARP-Broadcast und somit das WOL-Paket auslöst.
Ich würde mir WOL nur bei HTTP bzw. HTTPS Paketen an Port 80/443 wünschen. ABer das ist wohl nicht konfigurierbar - WOL weckt wohl bei jedem Mist auf??
Arg spät, Zeit zum Schlafengehen ...
Cruiser07
Es gibt ARP-Broadcasts "Who has 192.168.1.31? Tell 192.168.1.1":
1370 22:21:20.399088 24:65:11:6c:70:34 Broadcast ARP 42 Who has 192.168.1.31? Tell 192.168.1.1
192.168.1.31 ist die DS, 192.168.1.1 die Fritzbox 7390.
2 Sekunden später sehe ist das MagicPacket mit dem WOL Protokoll.
Broacdcast ARP und WOL kommen noch ein paar Mal, bis sich die DS mit einem IGMPv3 Paket meldet - aber an Zieladdresse 224.0.0.22 (siehe http://en.wikipedia.org/wiki/Multicast_address):
3129 22:22:32.020750 192.168.1.31 224.0.0.22 IGMPv3 60 Membership Report / Join group 224.0.0.251 for any sources
Warum gibt es den ARP-Broadcasts "Who has 192.168.1.31? Tell 192.168.1.1"?
3s vor diesem ARP wurden von dem internen WLAN-Router (alte Fritzbox, an der momentan ein iPad angemeldet ist) 192.168.1.29 mehrere SSDP-Pakete geschickt, an 239.255.255.250:1900. Siehe http://de.wikipedia.org/wiki/Simple_Service_Discovery_Protocol: "... ist ein Netzwerkprotokoll, welches zur Suche nach UPnP-Geräten im Netzwerk dient."
Hier scheint wohl das iPad am internen Router eine UPnP-Suche zu machen, die dann den ARP-Broadcast und somit das WOL-Paket auslöst.
Ich würde mir WOL nur bei HTTP bzw. HTTPS Paketen an Port 80/443 wünschen. ABer das ist wohl nicht konfigurierbar - WOL weckt wohl bei jedem Mist auf??
Arg spät, Zeit zum Schlafengehen ...
Cruiser07
Ja, in der Fritzbox habe ich dieses Feature (auf der Seite mit der Portweiterleitung) deaktiviert. Das hat aber noch nichts genützt, da dieses Feature das WOL nur bei externem Zugriff aus dem Internet macht.
Meine Network Traffic Analyse mit WireShark hat aber gezeigt, dass das WOL-Paket aufgrund Aktivität eines iPods im LAN kam.
Ich finde in der Fritzbox bisher keine Möglichkeit, das Aufwecken durch ein WOL Magic Packet ausschließlich auf externe Zugriffe hin zu aktivieren, nicht jedoch für Pakete, die aus dem LAN kommen.
Oder noch besser, es sollte nur bei HTTP bzw. HTTPS Requests auf die PhotoStation aufgeweckt werden (diese könnte auch mal nachts aus dem LAN kommen - allerdings kann man in diesem Fall auch zur DS laufen und sie per Taste hochfahren).
Erst nachdem ich auch in der DS WOL deaktiviert hatte, hat die DS heute Nacht durchgeschlafen. Aber damit ist das Kinde mit dem Bade ausgeschüttet - Wenn die DS heruntergefahren ist, dann kann niemand von extern mehr auf die PhotoStation. Und das ist kaum akzeptabel.
Cruiser07
- Registriert
- 03. Sep. 2012
- Beiträge
- 31.591
- Reaktionspunkte
- 3.323
- Punkte
- 854
Sorry, Du hast recht, ich habe nicht genau genug gelesen. Hast Du einmal gegooglt, ob es Möglichkeiten gibt, die Verwendung des WOL-Magic-Pakets seitens des iPods zu unterbinden?
Ja, habe ich jetzt. Aber nichts gefunden.
Sieht mir nach einer funktionalen Lücke der Fritzbox aus, die zu unspezifisch das WOL-Paket verschickt.
Wie gesagt, ich würde gerne steuern, dass nur HTTP bzw. HTTPS Requests an die PotoStation (http://nas-host/photo) das WOL-Paket auslösen. Aber diese feine Steuerung ist m.E. nicht möglich. Mal sehen, vielleicht versuche ich mal einen Vorstoß beim AVM.
Cruiser07
- Registriert
- 03. Sep. 2012
- Beiträge
- 31.591
- Reaktionspunkte
- 3.323
- Punkte
- 854
Sollte der iPod im LAN ein WOL Magic Paket senden, was soll die FB dann machen? Die hätte damit nichts zu tun. In dem Fall müsste das Problem an der Wurzel angepackt werden: der iPod sollte nicht einfach irgendwelche Magic Pakets schicken. Aber warum sollte er das überhaupt tun, das verstehe ich nach wie vor nicht.
Ich hatte nicht geschrieben, dass das iPad selbst das Magic Packet schickt. Das kommt schon vom Router.
Den Auslöser des WOL Magic Packets hatte ich oben geschrieben:
Warum gibt es den ARP-Broadcasts "Who has 192.168.1.31? Tell 192.168.1.1"?
3s vor diesem ARP wurden von dem internen WLAN-Router (alte Fritzbox, an der momentan ein iPad angemeldet ist) 192.168.1.29 mehrere SSDP-Pakete geschickt, an 239.255.255.250:1900. Siehe http://de.wikipedia.org/wiki/Simple_...very_Protocol: "... ist ein Netzwerkprotokoll, welches zur Suche nach UPnP-Geräten im Netzwerk dient."
Hier scheint wohl das iPad am internen Router eine UPnP-Suche zu machen, die dann den ARP-Broadcast und somit das WOL-Paket auslöst.
Beantwortet das Deine Frage?
Cruiser07
- Registriert
- 03. Sep. 2012
- Beiträge
- 31.591
- Reaktionspunkte
- 3.323
- Punkte
- 854
Ja, wobei ich den Vorgang dann innerhalb der FB skurril finde. Weshalb löst die ein WOL-Paket aus bei einem ARP-Broadcast? Hast Du die aktuellste Firmware drauf? Vermutlich ...
Klar, die FB 7390 hat die neueste Firmware (siehe Setup-Beschreibung). Der Auslöser für ARP und nachfolgend WOL waren SSDP-Pakete des iPads. Nach deren Ursache habe ich nicht weiter gesucht - aus der Beschreibung in Wikipedia entnehme ich eine Suche nach UPnP-Geräten im LAN. Das war meine erste Beschäftigung mit Network-Sniffing und WireShark, und es war 01:00 Uhr nachts - da war ich mit dem soweit erreichten Ergenis zufrieden ;-)
Cruiser07
- Status
Kaffeautomat
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.
