xDSL.at

Hallo Zusammen !

An meinem Modem/Router "Pirelli PRGAV4202" der A1 hängt über LAN-Kabel ein NAS-System "Synology DS 213+".

Das NAS-System sollte wenn kein Zugriff darauf erfolgt nach 10 Minuten in den sogenannten "DeepStandby" gehen. Dies geschieht auch, aber wenige Sekunden darauf startet es wieder.

Ich habe nun einen im Synolgogy-Forum empfohlenen Test gemacht. Dabei wird das Netzwekkabel abgezogen. Ohne LAN-Kabel bleibt die DiskStation im DeepStandby. Wenn nur der Pirelli-Router über das LAN-Kabel verbunden wird bleibt sie wieder nicht im DeepStandby. Dies weist laut Synolgogy-Forum darauf hin, dass der Router den Deep-Standby der DiskStation verhindert indem er sichtlich regelmäßig Signale an die DS schickt.

Kennte jemand das Problem ? Hat jemand die selbe Kombination im Einsatz ?

Kann man durch eine Einstellung am Router verhindern dass dieser das NAS aufweckt ?

Tausch dein NAS mit dem in der A1 Community, der seins nicht wach kriegt...

Scherz beiseite, hilfreich wäre zu wissen, was es aufweckt...

was es aufweckt...

ich nehm wohl an das der Hostmanager in die Suppe spuckt.
Oder ist vl. die DMZ aktiv aufs NAS?

Sorry für die Fragen, bin auf dem gebiet ziemlicher Anfänger.

1) Was ist die DMZ ? Ist diese auf der Diskstation zu dekativieren ?
2) Wie kann ich feststellen, ob der Hostmanager das Problem ist. Mit welchen Einstellungen könnte man dann das Problem beheben ?

>"...Was ist die DMZ ? Ist diese auf der Diskstation zu dekativieren ?..."
DMZ steht für demilitarized zone und bezeichnet ein netz, in das aus sicherheitsgründen stärker exponierte rechner reingestellt werden. der begriff "DMZ" wird aber auch oft falsch für die bezeichnung eines exposed hosts/default servers verwendet, und genau das meint der skyrim.
ein exposed host/default server ist ein rechner im lan, zu dem der ganze schlunz, der wanseitig reinkommt, vom zugangsrouter weitergeleitet wird.
wenn du jetzt
1.
deinen nas als exposed host gesetzt hast und
2.
der nas so konfiguriert ist, daß er nicht nur mit magic packets, sondern auch mit ip/tcp/udp geweckt werden kann, dann
3.
ist es nur eine frage der zeit, bis das ding aufgeweckt wird, weil ja dauernd irgendein schlunz reinkommt.
abhilfe:
nas nicht als exposed host setzen oder so konfigurieren, daß er nur auf magic packets reagiert.

wie du richtig erkannt hast, kann auch das pire selbst oder ein rechner im lan der wecker sein, weil heuzutage im default so ziemlich jeder schmarrn (upnp/ssdp, netbios, ipp, igmp, zeroconf/mdns, dhcp...), den man sich vorstellen kann, aktiv ist. das problem dabei: diese dienste senden in regelmäßigen abständen multi- oder net directed broadcasts raus, die den nas wecken können.
abhilfe: nas so konfigurieren, daß er nur auf magic packets reagiert oder alle verdächtigen dienste im lan deaktivieren.

als kleines beispiel, was da so alles passieren kann, eine lustige episode, die ein freund, dessen netzwerke wirklich sehr sauber angelegt sind, vor etwas längerer zeit erlebt hat. mein freund verwendet wol/wow, um bei bedarf einige rechner in seinen lans zu wecken. das zeugs funkte out of the box, und genau das war dann letztendlich auch das problem- keine kontrolle der bios-einstellungen...
"entdeckt" wurden diese unsauberen bios-einstellungen rein zufällig, als eines tages der neffe bei meinem freund aufkreuzte, weil er wieder mal zoff mit seinem laptop hatte. die zwei hängen den lapi in ein lan und starten ihn. und siehe da, auf einmal starten auch 2 pcs, die im gleichen lan angesiedelt sind.
die verwunderung war groß, wie du dir vorstellen kannst, und wurde noch größer, als sich diese "erscheinung" nach mehreren versuchen als reproduzierbar erwies- juhuu, der "magic button" is endlich da!
gut, ein kleiner blick in den shark, und alles war klar. der neffe ist eins jener genies, die eine ip nicht von einem autokennzeichen unterscheiden können, und muß deshalb dhcp verwenden. tjo, und beim start des lapis schickte der dhcp-client discovers raus, die die 2 rechner meines freunds aufweckten.
fazit der gschicht:
manchmal sind gurken im lan doch ganz nützlich...

lg
zid

@Zid: Danke für Deine ausführliche und fundierte Antwort !

Ich denke eher nicht, dass das NAS von außen (ausserhalb meinnes LANs) aufgeweckt wird sondern dass der Pirelli-Router selbst ständig irgenwas raus schickt. Um das auszuschliessen kann ich aber (sobald ein größerer gerade laufender Download abgeschlossen ist) noch das Telefonkabel von meinem Router entfernen. Dann kann nichts von aussen rein kommen.

Bezüglich Zugriff von Aussen: Ich möchte auch von außen auf meine "PhotoStation" der Diskstation zugreifen um auf mein Fotosammlung zugriff zu haben. Dazu sind am Router einige Port unter "Port-Forwarding" freigegeben. Für den Zugriff von Aussen habe ich am NAS ein DDNS eingerichtet. Das funktionert einwandfrei und bei Zugriff von aussen wird das NAS auch aufgeweckt.

Ich habe jetzt mal am Pirelli-Router nachgesehen. Dort habe ich folgende EInstellungen:
1) Unter "Sicherheit" / "DMZ-Host" ist keine IP-Adresse eingestellt.
2) Unter Erweitert" / "DiskManagament": ist deaktiviert
3) Unter "Erweitert" / "Media Sharing" hatte ich einen Ordner "DLNA-Shared" aktiviert. Das stammt sichtlich noch davon als ich mal getestet habe ein Verzeichnis auf einer angeschlossenen USB-Festplatte für DLNA freizugeben. Ich denke dass ich das nicht mehr benötige wenn der MedienServer am NAS die Zugriffe über DLNA abwickelt, oder ? Ich habs jetzt mal deaktiviert. Brachte aber keine Änderung.
4) Unter "Erweitert" / "UPnP" ist die 2. Option "Automatisches Aufräumen von alten, unbenutzten UPnP-Diensten aktivieren" aktiviert
5) Unter "Erweitert" / "Wake Up on LAN" habe ich "LAN-Ethernet" aber keine MAC-Adresse eingestellt.
6) Unter "Erweitert" / "Webserver" ist nichts aktiviert
7) Unter "Systemüberwachung" ist die Option "Automatische Aktualisierung" eingeschaltet. Hab das auch versucht auszuschalten - keine Änderung.
8 ) Das NAS hat eine fixe IP-Adresse in meinem Netzwerk.

Können diese Einstellungen dafür verantwortlich sein ?

Als Software-Version verwende ich "4.8.3.DWVV_TAU_5.1.6". Hab bei der Neuinstallation ein Downgrad gemacht weil das Modem immer deaktiviert wurde aber bei Bedarf nicht wieder aktiviert. Diese in den Foren empfohlene Lösung mit dem Downgrad brachte dann nach vielen Stunden die Lösung für dieses Problem.

seehr interessant...

hallo wolfgang,

>"...Das funktionert einwandfrei und bei Zugriff von aussen wird das NAS auch aufgeweckt..."
heißt das jetzt, daß du einfach von außen auf den nas gehst, und das ding wacht *ohne* magic packets auf? wenn das zutrifft, dann ist das nas-bios so eingestellt, daß der nas auch von ganz normalen ucasts geweckt werden kann.

die punkte #1-#6 schauen schon sehr appetitlich aus, wir machen damit gleich weiter.

- unter Erweitert > Routing:
IGMP deaktivieren. am besten räumst du dann auch gleich den aontv stack aus.

- Erweitert > Druckserver deaktivieren.

- Erweitert > Fileserver deaktivieren.

- Erweitert > WINS-Server deaktivieren.

- ferwartung der ta ausräumen oder deaktivieren. sonst läufst du gefahr, daß ein auto-upgrade auf 5.3.5 durchgeführt wird, und du bist wieder zurück am start.

die rhapsodie von früher war nicht nur für deine belustigung gedacht, sie enthält auch auch einen harten kern:
freundchen hat sofort mim wireshark nachgeschaut, was bei ihm abgeht. und auch du solltest das ergebnis deiner säuberungsaktion mim shark überprüfen- es dürfen im shark keine mcasts und bcasts (außer arp requests) vom pire aufscheinen. laß den kontrollrechner mindestens 10 min. rennen. falls noch irgendwelche m/bcasts auftauchen, möglicherweise hab ich was vergessen, dann den entsprechenden dienst unter "Erweitert > ..." deaktivieren.
wenn am ende das pire sauber ist- der shark rennt weiter- nas ans pire hängen, starten und danach auf tauchstaton schicken. und sollte der nas dann doch noch aufwachen, dann schaust du nach, was zum zeitpunkt der auferstehung im shark abgegangen ist.
falls du dich bei den traces nicht auskennst, .pcap gezippt hier posten.

btw. hast du adsl oder vdsl?

lg
zid

autsch, schon wieder was vergessen...
igmp muß auch auf der LAN Bridge deaktiviert werden:
unter
Netzwerkverbindungen > LAN Bridge > Routing
hakerl bei IGMP rausnehmen.

zu ssdp:
das zeugs wird auch von tr064 verwendet, und tr064 ist am pire im default aktiv. ich glaub zwar nicht, daß das ssdp dein böser wecker ist, trotzdem solltest du das tr064 deaktivieren:
unter
Erweitert > Fernverwaltung
hakerl bei TR-064 rausnehmen.
und wennst schon auf dieser maske bist, kannst auch gleich bei TR-069 das hakerl rausnehmen.

lg
zid

Hallo Zid

Ich habe jetzt alle von Dir angegebenen Sachen inkl. IGMP sowie das "SSH" am Pirelli deaktiviert. Damit sollte eigentlich alles ausgeschaltet sein. Hab es dann zur Vorsicht auch mal durchgestartet. Danke auch für den Tip die Fernwartung zu deaktivieren. Hab ich damals aber eh gleich alles inkl. tr064 deaktiviert um ein Update zu verhindern.

Die Diskstation ist so eingestellt, dass sie nach 10 min Inaktivität in den Standby und nach weiteren 60 sec. in den DeepStandby geht. Weiters habe ich die Option "Broadcasting-Pakete von Windows ignorieren" aktiviert.

Als ersten Test habe ich mal die ADSL-Leitung abgehängt - keine Änderung - also von aussen dürfte nichts störendes rein kommen.

Habe mir das Tool Wireshark installiert und laufen lassen. Habe dabei sämtliche Geräte ausgeschaltet die sonst noch im LAN bzw. WLAN hängen. Es blieben nur folgende Geräete im Netz:
- 10.0.0.138: Pirelli-Router
- 10.0.0.9: Laptop mit laufendem Tool
- 10.0.0.7: NAS "Diskstation 213+"

Vielleicht darf ich Dich bitten einen Blick auf das beigefügte Protokoll zu blicken. Mit Deinem Expertenblick liest wahrscheinlich schnell was raus als ich als Beginner auf diesem Gebiet.

Ich habe den Scan ca. 15 min laufen lassen. Dabei ist das NAS zwei mal in den Deep-Standby gegangen und sofort wieder gestartet. Bei folgenden Zeilen-Nummern (ca.) des Protokolls hat das NAS folgendes gemacht:
291 Standby
399 DeepStandby
415 Start

1997 Standby
2107 DeepStandby
2125 Start

Läßt sich da rauslesen wer/was der Übeltäter ist ?

Mir fällt auf dass in beiden Fällen genau zu dem Zeitpunkt wo das NAS aufwacht ein Eintrag ist "Who has 10.0.0.7"
(410 180.087462000 AdbBroad_71:6d:dd Broadcast ARP 60 Who has 10.0.0.7? Tell 10.0.0.138)
(2118 930.125586000 AdbBroad_71:6d:dd Broadcast ARP 60 Who has 10.0.0.7? Tell 10.0.0.138)
also sichtlich das Pirelli fragt wer die IP-Adresse des NAS hat das dann sichtlich darauf antwortet und dafür aufwacht.

Dachte eigenltich, dass genau das mit der am NAS aktivierten Option "Broadcasting-Pakete von Windows ignorieren" verhindert werden sollte.

Danke für Deine Hilfe schon mal !

Sorry, hier noch das Log-File

jetzt auch wirklich das Log-File als ZIP

Läßt sich da rauslesen wer/was der Übeltäter ist ?

Mir fällt auf dass in beiden Fällen genau zu dem Zeitpunkt wo das NAS aufwacht ein Eintrag ist "Who has 10.0.0.7"

Jop - Hostmanager
Wie vermutet

Was kann ich nun dagegen tun ?

Im Forum der Synology Diskstation habe ich einen Auszug gepostet und folgende Antwort erhalten:
---
das sind ganz "normale" ARP-Requests, um die MAC-Adresse einer bekannten IP-Adresse zu ermitteln. Dass die die DS aufwecken soll, glaub ich nicht, das läuft fast schon "in Hardware" (meinen DSen macht das nichts aus). Interessanter ist eher, was der Router danach noch von der DS will. Kommt dann noch mehr Traffic?
Mit "Broadcasting-Pakete von Windows ignorieren" hat das nichts zu tun.
---

sry, jungs. mußte gestern weg, und das war dann eine jener "länglichen" sitzungen, auf die ich gern verzichte...grml.

zur sache:

1. hostmgr und arp requests
wir sind uns hoffentlich über diese 2 punkte einig:
i. abhängig von den fähigkeiten und einstellungen des bios können netzfähige geräte durch alles mögliche geweckt werden. mit einer ausnahme-
ii. arp requests. in einem ethernet/ip-basierten netz kommt man an arp nicht vorbei, und wenn ein rechner durch arp reqs geweckt werden könnte, dann würde er gar nicht zum schlafen kommen, weil **dauernd** **alle** netzgeräte arp reqs rausgeschicken, um ihre arp caches zu aktualisieren.
und da hostmgr die nud states im arp cache abfragen oder/und mit arp reqs aktiv bekannte geräte im lan pollen, kann ein hostmgr nicht der wecker sein.

2. sehr schöne säuberungsaktion am pire
mein kompliment, wolfgang. das pire ist wirklich sauber ausgeräumt, könnte man in dem zustand sogar produktiv einsetzen.
deine gepostete trace umfaßt einen zeitraum von 940s. in dieser zeit müßte man bei einer unsauberen säuberungsaktion *g* auf alle fälle die m/bcasts der folgenden dienste sehen:
- igmp- membership query interval im default 125s
- ssdp- notify interval um die 6 min
- netbios-ns, netbios-dgm- die verschiedenen query/announcement intervalle hab ich jetzt nicht im kopf, sie sind aber sicher kleiner als 940s.
gut, und wenn man jetzt deine trace mit dem ansichtsfilter ip.addr==10.0.0.138 betrachtet, dann sieht man nur ucast traffic zwischen lapi (10.0.0.9) und pire (10.0.0.138).

3. das pire ist nicht das prob, sondern...
ziemlich sicher dein "kontrollrechner". wenn ich nämlich den ansichtflter ip.addr==10.0.0.9 setze, dann krieg ich eiterwimmerl am a****. das ist sicher kein rechner, der den anforderungen an einen kontrollrechner genügt, die da lauten:
i. es dürfen keine server oder serverähnliche anwendungen rennen. der output von
$ netstat -ta
und
$ netstat -ua
muß leer sein.
ii. es dürfen auch sonst keine anwendungen laufen, die irgendeinen "automatischen" und unnötigen traffic generieren.
puristen verwenden bei kontrollrechnern minimalbetriebssysteme und verzichten dabei manchmal sogar auf das gui- nixi shark, sondern tcpdump pur-, nur um sicherzustellen, daß keine artefakte durch den kontrollrechner eingeschleppt werden. ok, so puristisch wollen wir jetzt nicht sein, dennoch befürchte ich, daß eben dein "kontrollrechner" der lauser ist, und diese vermutung muß jetzt...

4. ...überprüft werden
du hängst *nur* den nas ans pire, läßt ihn in den schlaf fallen und wartest ab... solltest du ein ungeduldiger mensch sein, dann geh halt ins wirtshaus oder auf ein festl oder wwi. und wenn der nas "hinreichend" lang gepennt hat, dann hängst du deinen "kontrollrechner" (10.0.0.9) ans pire. der nas sollte danach aufwachen...

lg
zid

@Zid: Besten Dank, daß Du Dir die Zeit genommen hast um mein Protokoll so genau zu durchleuchten !

Leider habe ich nur den einen Rechner zur Verfügung. Da das mein Arbeitsrechner ist läuft auch wirkich so einiges darauf.

Habe jetzt für ca. 30 min. meinen Rechner ganz ausgeschaltet. Damit waren nur noch das NAS und das Pirelli-Modem im Netzwerk. Mit dem Ergebnis, dass das NAS auch nicht in den DeepStandby ging

Wenn das mal einer versteht ...