Pireli 4202N weckt NAS-System ständig aus Standby auf

[wolfgang67]

Hab jetzt nochmal eine Antwort vom Synology-Support bekommen:
"Since the packet is from router and we could not block them, it should be an router problem for this hibernation issue.
This router uses ARP request frequently to manage it's ARP table since there is no other client on the router, only DS.
We could not change this behavior and only the vendor could do it. We suggest you to change another router or contact the vendor to see if they could change such mechanism."

So wie ich es verstanden haben sendet doch jeder Router regelmäßig ARP-Requests, oder ?
Wieder typisch dass sie sich gleich damit abputzen, dass das Problem am anderen Gerät liegt !

[zid]

hallo wolfgang,

das einfache zuerst...

>"...Wieder typisch dass sie sich gleich damit abputzen, dass das Problem am anderen Gerät liegt !..."
es ist bekannt, daß unternehmen derartige tendenzen an den tag legen, *und genau deshalb* hab ich dir empfohlen, die tests vom sin abzuwarten. wenn du den leuten deine traces zusammen mit seinen vergleichstraces + entsprechenden kommentaren schickst, dann kommen die mädels und jungs daran nicht vorbei, und dir bleiben so unnötige mails wie jenes von oben erspart. angesichts *deiner* optionen sind das leere kilometer. du hast gleich doppeltes schwein und befindest dich schon einer ziemlich exquisiten situation:
1.
der sin hat sich gemeldet und uns mitgeteilt, daß die ds212+ bei aktiviertem hostmgr sehr wohl im deepsleep mode bleibt. und- und das ist noch um ecken besser-
2.
der junge ist bereit, für dich die entsprechenden vergleichstests durchzuführen, was wegen seinen lokalen gegebenheiten doch mit einem gewissen aufwand verbunden ist. hab grad gestern mit ihm in einem 1,5-stündigen telefonat diskutiert, wie man die tests am gschicktesten anlegen könnte, sodaß bei dieser aktion nicht gleich die halbe bude zerlegt wird.
gedulde dich also bitte etwas, wir melden uns, sobald ergebnisse vorliegen. aja, deine mail-adr. würd ich gelegentlich auch brauchen.

>"...So wie ich es verstanden haben sendet doch jeder Router regelmäßig ARP-Requests, oder ?..."
nicht nur jeder router, sondern *jedes* netzfähige gerät, das auf basis ip + ethernet arbeitet. wie sonst willst du eine ip zu einer mac auflösen? irgendwann mußt du von l3 auf l2, und das ist auch nicht das problem im zusammenhang mit irgendenwelchen ruhezuständen. da stellen sich nur 2 fragen:
1.
schickt ein netzgerät im lan vor dem löschen eines arp eintrags noch eine abschließende arp req raus oder nicht (s. hier letzter absatz)? wenn ja, dann kanns mit ruhezuständen zoff geben- und das mit *jedem* gerät, das nach diesem muster gestrickt ist.
2.
ist ein hostmgr an einem router im lan aktiv, der alle bekannten geräte in regelmäßigen zeitintervallen mit arp reqs pollt. wenn ja, dann kanns mit ruhezuständen zoff geben, und man tut gut daran, das zeugs zu deaktivieren. beim pire spielt da noch ein zusätzliches problem rein, weil der hostmgr mit dem dhcp-server zu einem idyllischen einheitsbrei vermengt wurde, sodaß er meines wissen nur deaktiviert werden kann, indem man den dhcp-server abdreht. dieses problem hättest du bei den sts/tgs nicht, weil diese geräte flexibel angelegt sind und deshalb auch die bezeichnung (modem)router verdienen. so gesehen war der *absolut grundlose* wechsel (du scheinst ja noch immer adsl zu haben) von st585v6 auf pire die volle breitseite ins eigene knie.
mehr isses nicht...

lg
zid

[zid]

aaaah, das war gut, das war ein hochgenuß...

hallo wolfgang,

hatte grad eine sehr nette session mim sin und fasse seine testergebnisse kurz zusammen:

1.
die ds212+ beantwortet im deepsleep die arp reqs von hardping

ds212_hardping_no_wake_up.png (20.01 KiB) 19275-mal betrachtet

wacht dabei aber nicht auf (10.0.0.15 ist der kontrollrechner, 10.0.0.10 ist die ds). und auch sonst ist sie im deepsleep ziemlich aufgeweckt unterwegs.

2.
der hostmgr kann die ds212+ mit seinen arp reqs nicht wecken. nach #1 eh klar, und das wurde auch experimentell bestätigt.
bei diesem test hat der sin so ganz nebenbei ein sehr schönes feature des tg entdeckt, das ich bis heut nacht nicht kannte und das zumindest für sin und mich in die kategorie "netzwerktechnik mit der feinen klinge" fällt. ich werd darüber noch in einem getrennten faden berichten, sobald ich die erkenntnis vom sin sauber aufgearbeitet hab.

der fahrplan sollte somit klar sein:

- sins .pcaps sind schon bereinigt, ich muß nur noch ein paar kommentare zu den testdetails schreiben und laß dir dann das ganze zeugs zukommen.

- du schickst deine tests zusammen mit jenen vom sin zu synology. das diesbezüglichle begleitmail kannst du durchaus schlank halten, genaugenommen genügt ein einziger satz, z.b.:
"ich möcht, daß in der ds213+ in hinblick auf deepsleep die technologie der ds212+ drin ist."
der rest gehört synology.

lg
zid

[wolfgang67]

Hallo zid, hallo sin !

Den Support-Call an Synolgoy hatte ich bereits geschickt bevor ihr den Test geplant hattet.

Ein herzliches DANKESCHÖN, dass Ihr beide Euch diese Mühe macht !!!!!!!!!!!!!!!!

Wirklich interessant, das die DS212+ bei einem ARP-Request schön weiter schläft.
Mit diesen Testergebnissen sollte Synology ja wirklich was anfangen können.

lg
Wolfgang

[zid]

alles retour...

hallo wolfgang,

hab jetzt den dhcp-server des pires durchwühlt. es scheint doch eine möglichkeit zu geben, diese quasselstrippe von hostmgr selektiv zum schweigen zu bringen. mit telnet aufs cli des pires gehen und dann:

Code: Alles auswählen

OpenRG> conf set dev/br0/dhcps/ip_auto_detect/disabled 1
OpenRG> flash commit

WICHTIG: pire danach rebooten!
bei mir hält der hostmgr jetzt immerhin schon gut 1000s die klappe, und der dhcp-s ist aktiv.

lg
zid

[zid]

hm, hm, hm...*kopfkratz*

hallo wolfgang,

ich geh grad nochmal die traces vom sin durch und mir ist schon heut nacht aufgefallen, daß die ds212+ im deepsleep mode noch immer eine erstaunliche netzwerkaktivität entwickelt, sogar netbios rennt. das ging sogar so weit, daß ich am anfang dachte, daß die 10.0.0.10 der kontrollrechner vom sin ist, und erst über die oui (synology = 00-11-31) hab ich dann erkannt, daß die 10.0.0.10 in wirklichkeit die ds ist. bei deinen traces hingegen ist mir diese hohe netzaktivität nicht aufgefallen. kann jetzt natürlich zufall sein- deine ds ist anders konfiguriert als die vom sin z.b... dennoch würd ich gern der sache auf den grund gehen. wenn nämlich der deepsleep mode der ds213+ nicht ident ist mit jenem der ds212+, dann ist ein parallelvergleich der beiden geräte nicht oder nur eingeschränkt zulässig.
ich würde deshalb von dir den folgenden test brauchen:

- du verbindest deinen kontrollrechner direkt mit der ds, startest den shark und läßt die ds in den deepsleep fallen.

- danach rührst du das ganze system für 30 min. nicht an.

- nach ablauf der 30 min. stoppst du den shark, sicherst die trace als .pcap und schickst sie mir.

lg
zid

[Sin10]

eine ganz interessante geschichte.
Meine DS feuert frisch fröhlich vor sich hin, während sie brav schläft - sogar tcp session keep alive pakete werden an meine dreambox verschickt, denn die ist wie schon geschrieben via nfs eingebunden.

nur mal zum vergleich, so sehn meine energie einstellungen aus auf der DS212 .. sieht das bei dir gleich aus?

ds212_enegie_optionen.JPG (58.31 KiB) 19182-mal betrachtet

[wolfgang67]

alles retour...
hallo wolfgang,
hab jetzt den dhcp-server des pires durchwühlt. es scheint doch eine möglichkeit zu geben, diese quasselstrippe von hostmgr selektiv zum schweigen zu bringen. mit telnet aufs cli des pires gehen und dann:

Code: Alles auswählen

OpenRG> conf set dev/br0/dhcps/ip_auto_detect/disabled 1
OpenRG> flash commit

WICHTIG: pire danach rebooten!
bei mir hält der hostmgr jetzt immerhin schon gut 1000s die klappe, und der dhcp-s ist aktiv.
lg
zid

Hallo zid !

Habe jetzt auch noch Deinen Tip ausprobiert über Telnet am Pirelli den hstmgr auszuschalten.

--------------
OpenRG> conf set dev/br0/dhcps/ip_auto_detect/disabled 1
Returned 0
OpenRG> flash commit
Returned 0
OpenRG>
--------------

Ergebnis:
- Meine DS213+ war jetzt 15 min lang im DeepSleep !
- Ein Zugriff (auch von aussen) weckt die DS schön auf
- Meine WLAN-Geräte mit DHCP können sich weiter am Router anmelden
--> Sieht echt gut aus

Werde jetzt mal weiter beobachten, ob dieser schöne Zustand auch weiter anhält und dann berichten.

[zid]

es geht nix über einen stetig steigenden unterhaltungswert...

hallo jungs,

hab jetzt doch ein zeiterl gebraucht, all eure versuchsergebnisse aufzudröseln. doch der reihe nach...

1. deine ds213+, wolfgang, verhält sich wie ein toter hund..."
wenn ich bei deiner 30min.pcap den ansichtfilter eth.addr==<mac-deiner-ds> setze, dann krieg ich ein leeres fenster (screenshot erspar ich mir in dem fall ), d.h. deine ds existiert netztechnisch überhaupt nicht.

2. wir reden im zusammenhang mit der ds212+ und ds213+ über 3 verschiedene ruhezustände...
...aber nicht über den "deepsleep" mode.
ich hab auf synology.com diese begriffserklärung gefunden:
http://www.synology.com/support/faq_sho ... 7&lang=enu
deepsleep steht also nicht zur diskussion, sondern nur hdd hibernation und system hibernation- bei der ds213+. das paßt auch zu ihren hw. specs (-> power consumption):
http://www.synology.com/products/spec.p ... #p_submenu
anders verhält es sich bei der ds212+. dort gibts nur den hdd hibernation mode (->power consumption):
http://www.synology.com/products/spec.p ... #p_submenu
und der unterscheidet sich vom hdd hibernation der ds213+, sodaß man es ingesamt eben mit 3 modi zu tun hat:

- ds212+ hdd hibernation:
hdd und lüfter down,
cpu und netzwerk voll da,
kein zoff mit dem hostmgr -> tests vom sin.

- ds213+ hdd hibernation:
hdd down,
lüfter, cpu und netzwerk voll da,
kein zoff mit dem hostmgr -> tests vom wolfgang.

- ds213+ system hibernation:
hdd, lüfter, cpu down,
kein netzwerk und zoff mit hostmgr -> tests vom wolfgang.

3. "ich möcht, daß in der ds213+ in hinblick auf deepsleep die technologie der ds212+ drin ist."
diese forderung kann angesichts der neuen erkenntnisse nicht mehr gehalten werden, dennoch bleibts bei einem satz:
"ich möcht, daß in der ds213+ in hinblick auf hdd hibernate die technologie der ds212+ drin ist."
mods beim system hibernation werden "weniger" möglich sein (cpu down), man kriegt also in hinblick auf energieeinsparung sicher nicht "die volle kanne", könnte aber mit einem modifizierten hdd hibernation die(das) lüfter(geräusch) abstellen.
frage ist jetzt halt, ob sich die ds213+ ohne lüfter überhaupt (stabil) betreiben läßt. die hw. könnte z.b. thermisch anspruchsvoller sein, oder die 213er ist vom gesamtdesign her thermisch enger ausgelegt, oder...wwi.
ich denke, daß man dieser frage zuerst mal nachgehen sollte.

>"...Meine DS213+ war jetzt 15 min lang im DeepSleep..."
penner! die soll hackln...

lg
zid

[wolfgang67]

>"...Meine DS213+ war jetzt 15 min lang im DeepSleep..."
penner! die soll hackln...

lg
zid

Hallo zid

Meine Diskstation hat Dich sichtlich erhört...

Hatte mich schon gefreut, dass meine DS 2 Tage lang durchgeschlafen hat und nur wenn ich mal über meine HandyApp darauf zugegriffen habe wach wurde um anschließend wieder brav wieder schlafen zu gehen.

Heute habe ich mal wieder meinen Laptop (Windows 7) ins Netz gehängt. Ab da ist die DS dann regelmäßig (wenn auch in längeren Abständen) wieder gestartet - nichts wars mehr mit durchgängigem Schlafen. So sollte das ja genau sein.

Hab gleich mal mit Wireshark ein Netzscan gemacht (siehe Anhang). Zu dem Zeitpunkt (Zeile 584) als die DS los startet hat sichtlich meine Laptop (10.0.0.2) nach ihrer IP-Adresse (10.0.0.7) gefragt. Sichtlich sendet also auch mein Laptop ARP-Requests aus.

Habe im Synology folgenden Link gefunden: http://www.windows7-tuning.de/tuning-ti ... abensuche/
Damit kann man sichtlich Windows-7 dazu bringen nicht mehr regelmäßig nach Netzwerk-Geräten zu suchen.
Dankst Du dass das helfen würde oder kennst eine andere Lösung ?

Müsste allerdings vorher abchecken, ob ich das abschalten kann ohne im Firmennetzwerk in dem der Laptop sonst hängt Probleme zu kriegen.

lg
Wolfgang

[Sin10]

Habe im Synology folgenden Link gefunden: http://www.windows7-tuning.de/tuning-ti ... abensuche/
Damit kann man sichtlich Windows-7 dazu bringen nicht mehr regelmäßig nach Netzwerk-Geräten zu suchen.
Dankst Du dass das helfen würde oder kennst eine andere Lösung ?

normalerweiße darf sie davon nicht aufwachen.
Meine wacht nur beim ersten start von windows auf, danach ist eigentlich ruhe. Versuchen kannst du das jedoch.

[wolfgang67]

Hallo !

Melde mich mal wieder um über den aktuellen Stand zu berichten. Bin ja nach wie vor beim Synology-Support dran um zu erreichen dass die Diskstation bei ARP-Request nicht mehr aufwacht.

Hab die letzte Tage mehrfach mit dem Support hin und her gemailt. Möchte Euch daran teilhaben lassen welche Spezialisten da am Werke sind. Wenns nicht so traurig wäre, wärs ja fast zum Lachen:

Zuerst bitten Sie mich das Tool Wireshark zu installieren und einen Scan zu schicken. Hab sie darauf hingewiesen dass ich einen solchen Scan mit einer langen Beschreibung bereits geschickt hatte, hab aber nochmals den wichtigsten Ausschnitt aus der Beschreibung und den Scan geschickt:
---------- Von mir an Synology: ----------
Find again the protocol-file from 11.Jan.2013. My DiskStation has IP 10.0.0.7, the router 10.0.0.10.
The DiskStation (10.0.0.7) starts from system standby about line 30. In the protocol-file you can find the entries:
“32 14.135364000 Dell_33:0c:46 Broadcast ARP 42 Who has 10.0.0.7? Tell 10.0.0.10”
“34 15.006595000 Dell_33:0c:46 Broadcast ARP 42 Who has 10.0.0.7? Tell 10.0.0.10”
So you can see, that the DiskStation will wake up immediately from system standby when a ARP-request is sent to her IP-address !
-----

Von Synology kommt darauf folgendes zurück:
---------
Do you have any information about which device is 10.0.0.7 and 10.0.0.10 ?
---------

Lesen ist wohl wirklich nicht deren Stärke

Nachdem ich ihnen den Text mit den IP.Adressen nochmals groß und fett geschrieben habe kommt jetzt folgendes zurück:
-------------
The problem is, if the target of this broadcast is your DS, it will wake up, it is normal.
If the broadcast is not for your DS, your DS will not wake up. So in this case, it is normal since your router is looking for your NAS.
The problem is, why your router will look for it ? If there is no one looking for the IP of DS, why the router send the request ?
It should be the mechanism on your router.
-------------

Dazu meine Frage:
Ich habe das aus Deiner Beschreibung doch so verstanden dass in einem IP-ethernet Netzwerk der Router standardmäßig regelmäßig alle IP-Adressen die er in seiner List hat abfragt, oder ?

[Skyrim]

Hallo Wolfgang,

Ich habe das aus Deiner Beschreibung doch so verstanden dass in einem IP-ethernet Netzwerk der Router standardmäßig regelmäßig alle IP-Adressen die er in seiner List hat abfragt, oder ?

Öhm, eigentlich nicht nur von Router sondern auch von PC's resp. anderen Netzwerkgeräten
wie du schon festgestellt hast.

Ich denke, wenn ich mir das so durchlese, haben die Techniker dort ein leichtes
Verständnisproblem über die Funktionsweise der ARP-Request

[wolfgang67]

Das hab ich mir auch schon gedacht.
Hab das denen jetzt nochmal zurück gemeldet. Bin gespannt was zurück kommt...

[zid]

skyrim, du lauser, etwas mehr ehrfurcht vor den hl's...

hallo wolfgang,

>"...Ich habe das aus Deiner Beschreibung doch so verstanden dass in einem IP-ethernet Netzwerk der Router standardmäßig regelmäßig alle IP-Adressen die er in seiner List hat abfragt, oder ?..."
ich fasse unsre diskussion mal kurz zusammen, es gibt da mehrere themenbereiche:

I. potentielle störer von ruhezuständen:
1. arp
2. anwendungen, die regelmäßig bekannte geräte pollen, z.b. hostmgr.
3. mcasts und bcasts
störer können gundsätzlich *alle* geräte im lan sein, s.a. die ausführungen vom skyrim. wir reden also nicht nur über router, sondern ganz allgemein über geräte, die auf ethernet und ip aufsetzen.

II. was kann man überhaupt fordern?
theoretisch viel, praktisch leider nicht mehr ganz so viel. es gibt forderungen, die theoretisch realisierbar, aber praktisch nicht sinnvoll sind.


ad #I.1:
wenn du ein gerät a (ip: a.a.a.a/irgendwas) startest und mit diesem einem gerät b (ip: b.b.b.b/irgendwas) im lan ein packerl schicken willst, dann braucht a auf alle fälle die mac von b. schließlich muß an das zu versendende packerl ein ethernet header mit src- und dst-mac angeschraubt werden. und da a (gerade gestartet) die mac von b nicht kennt, fragt es mit einer arp request nach:
"who has b.b.b.b? tell a.a.a.a"
diese prozedur müßte jetzt beim versand jedes packerls durchlaufen werden, wenn die designer von arp nicht einen notizblock vulgo arp cache vorgesehen hätten. der rechner a eruiert also beim erstversand eines packerls nicht nur die mac von b, sondern schreibt sie auch gleich in seinen notizblock, sodaß er beim versand des nächsten packerls nicht mehr nachfragen muß.
blöderweise haben notizblöcke eine unangenehme eigenschaft- sie sind beschränkt und werden somit irgendwann mal voll. und genau deshalb haben die designer von arp einen radiergummi vulgo arp cache timeout definiert. jedes gerät prüft laufend die einträge im notizblock und radiert sie aus, wenn sie hinreichend lang nicht mehr gebraucht wurden. dadurch gibts immer platz im notizblock, das ding geht nie über.
blöderweise2 sind designer zwar geniale köpfe, aber auch richtige lauser- sie haben in ihren specs weder den arp cache timeout noch die "modalitäten" des ausradierens genau festgelegt. d.h. der arp cache timeout variiert mit hersteller/os/gerät (z.b. st/tg im default 15', cisco 4h...), und es kann durchaus passieren, daß ein gerät vor dem ausradieren eines eintrags noch kurz checkt, ob das gerät, dessen eintrag jetzt ausradiert werden soll, wirklich nicht mehr da ist- und das passiert natürlich mit einer arp req...
somit ist folgendes szenario denkbar:
du hast im lan ein gerät x, das einen arp cache timeout von- na, sagen wir mal- 2h hat und ein echter checker ist. deine ds büselt in aller gemütlichkeit schon seit 2h vor sich hin, und dann kommt der checker mit seiner arp req...


ad #I.2:
hostmgr und ähnliche anwendungen sind sehr beliebt bei den usern und werden deshalb auch sehr oft in low-end geräten implementiert. diese anwendungen zeigen dem user im klicki-bunti die aktiven geräte im lan an und bieten ihm damit eine sehr einfache möglichkeit festzustellen, ob der rechner, mit dem man grad arbeitet, auch wirklich gestartet ist. man verbindet sich nur kurz mit dem router, schaut dort nach, ob der rechner, mit dem man grad arbeitet, in der liste aufscheint und kennt sich sofort aus. das kapier sogar ich.
so ein komfort hat natürlich seinen preis:
diese anwendungen müssen pollen, um die geräteliste im klicki-bunti auf aktuellem stand zu halten. und egal wie dus aufziehst, an l2 (=arp) kommst du nicht vorbei.


ad #I.3:
will man auf arp verzichten, dann muß man zwangsläufig dienste auf basis bcast oder mcast aufziehen. und solche dienste sind dann auch geeignet, geräte aufzuwecken, müssen sie sogar. auf diesen sachverhalt wird sogar in der faq von synology hingewiesen.


ad #II
die ds213+ kennt zwei ruhezustände: hdd hibernation und system hibernation.
und jetzt stellt sich die frage, wo man mit seinen änderungswünschen ansetzen soll. naiv gesehen ist natürlich der system hibernation der erste kandidat:
die ds soll in diesem zustand arp reqs ignorieren.
damit rennt man aber in ein handfestes problem:
die ds läßt sich nicht mehr von einem gerät mit ucasts wecken, nachdem ihr arp eintrag im arp cache dieses geräts ausradiert wurde. und wenn die ds von einem gerät nicht geweckt werden kann, dann von keinem. alles nur eine frage der zeit.
ok, kann man grundsätzlich auch mit einem statischen arp eintrag lösen. nur erklär das mal papi, der sich- völlig unbelastet von einem wissen über arp, arp cache, timeouts, nud states- eine ds kauft. und dann gibts auch noch hinreichend viele geräte, auf deren arp cache man überhaupt nicht zugreifen kann: low-end router, router mit gesperrter fw., webcams, heizungssteuerungen, wasserstandsmesser für die klomuschel, wwi...
unterm strich fällt diese option flach, dir bleibt nur noch der hdd hibernate mode für änderungswünsche offen. und da kannst du höchstens eine anpassung an die ds212+ anstreben- vorausgesetzt, daß der wärmehaushalt der ds213+ mitmacht.

lg
zid