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

[zid]

dein syno is halt kein penner, der will hackln...

hallo wolfgang,

ich faß mal deine versuchsergebnisse zusammen, verlier nämlich langsam den überblick:
- wenn der nas vom lan getrennt ist, paßt alles. samma froh...

- wenn nas + rechner im dem pire verbunden sind, dann haut sich das ding aufs ohr, wird aber nach kurzer zeit geweckt.

- wenn nur der nas mit dem pire verbunden ist, dann schläft er gar nicht ein.

gut, wenn das jetzt stimmt, dann sind aus meiner sicht noch 3 fragen offen.
was passiert
- wenn du rechner + pc ans pire hängst, den nas einschlafen läßt und sofort danach das patchkabel des rechners vom pire abziehst?

- wenn du das wol am nas deaktivierst? beide situationen (i.e. nas allein und nas + rechner am pire) durchtesten.

- wenn du bei *reaktiviertem* wol den nas komplett abdrehst (per power button, webgui...)?
und wenn der nas nicht aufwachen sollte, kannst du ihn dann mit dem etherwake des pires wecken? dazu unter "Erweitert > Wake Up on LAN" die mac des nas eintragen und auf "Wake Up on LAN" klicken. laß dabei sicherheitshalber den shark am rechner mit dem ansichtsfilter
eth.type==0x0842
mitrennen. du solltest ein einzelnes naked magic packet sehen, und der nas sollte natürlich auch starten...

lg
zid

[zid]

hallo wolfgang,

also dieser hostmgr und die bemerkungen vom skyrim dazu haben mir jetzt keine ruhe gelassen. hab mir jetzt die von dir angegebenen, kritischen arp-sequenzen 291-415 und 1997-2125 nochmal angeschaut. der geistesgestörte hostmgr des pires pollt wie üblich im bekannten 10s-takt, ich frag mich schon immer, warum er nicht gleich im 0,0001s-takt pollt, dann hätte der geneigte user wenigstens keine probs mehr, weil das lan eh mit arp reqs geflutet werden würde.
egal, versuch jetzt bitte mal was unlogisches = standardprozedur beim pire und dreh den deppaten hostmgr ab, indem du unter "Erweitert > Verteilung der IP-Adressen" alles deaktivierst, was auch nur entfernt nach dhcp riecht.

lg
zid

aja, falls du dir die kritischen sequenzen anschauen willst, dann vielleicht mit diesen filter

- arp&&(frame.number>=291&&frame.number<=415||frame.number>=1997&&frame.number<=2125)
oder besser du machst gleich

- 2 fenster auf und setzt
arp&&frame.number>=291&&frame.number<=415
arp&&frame.number>=1997&&frame.number<=2125
damit kannst in aller gemütlichkeit zeilenweise vergleichen.

wo_crit_seqs.png (52.34 KiB) 22750-mal betrachtet

beachte die ähnlichkeit, der skyrim wird schon recht haben- wenn armut auf armut trifft, dann wirds unlustig

[wolfgang67]

@zid:
Mein NAS geht nach 10 min in den Standby und nach weiteren 60sec in den DeepStandby. Anschließend verhält es sich so:

1) bei abgezogenem LAN-Kabel am NAS: NAS bleibt im DeepStandby

2) wenn NAS nur mit dem Pirelli-Router vernunden ist und sonst kein anderes Gerät im LAN/WLAN hängt: NAS wacht sofort wieder auf sobald es im DeepStandby ist (auch wenn das DSL-Kabel beim Router abgezogen ist).

3) wenn NAS am Pirelli-Router hängt und auch der Laptop am Roter hängt: Verhalten ident mit Fall 2

4) wenn NAS direkt mit Laptop via LAN-Kabel verbunden:
Im Synology-Forum zu meinem NAS habe ich den Tip bekommen mal zu testen meinen Laoptop direkt mit dem NAS zu verbinden, ohne den Router dazwischen und folgenden test zu machen:
-------------------------------------------------------------------------------
Ob ARP-Requests die DS wecken, kannst du recht einfach testen:
- Gib dem PC und der DS eine statische IP und verbinde beide direkt (ohne Router)
- Warte bis die DS schläft
- Lösch den ARP-Cache des PCs mit "arp -d"
- Ping die IP der DS an, das löst zunächst mal einen ARP-Request aus, um die MAC der DS zu ermitteln, Kontrolle mit "arp -a"
Wacht die DS dabei auf?
- Warte bis die DS wieder schläft
- Ping die IP der DS nochmal an, diesmal ist die MAC noch im Cache
-------------------------------------------------------------------------------

Ergebnis: Zuerst geht das NAS nach 11 Minuten brav in den DeepStandby und bleibt dort auch. Aber beim Ping auf die DS wacht diese auf !
Interessanterweise sogar beim zweiten mal pingen wo die MAC eigentlich noch im Cache sein sollte.


Nachfolgend der Auszug:
--------------------------------------------------------

C:\Users\P20120>arp -d

C:\Users\P20120>ping 10.0.0.7

Pinging 10.0.0.7 with 32 bytes of data:
Reply from 10.0.0.7: bytes=32 time=1527ms TTL=64
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64

Ping statistics for 10.0.0.7:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1527ms, Average = 381ms

C:\Users\P20120>arp -a

Interface: 10.0.0.10 --- 0xb
Internet Address Physical Address Type
10.0.0.7 00-11-32-15-a1-0e dynamic
10.0.255.255 ff-ff-ff-ff-ff-ff static
224.0.0.252 01-00-5e-00-00-fc static
255.255.255.255 ff-ff-ff-ff-ff-ff static

C:\Users\P20120>ping 10.0.0.7

Pinging 10.0.0.7 with 32 bytes of data:
Reply from 10.0.0.7: bytes=32 time=1491ms TTL=64
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64

Ping statistics for 10.0.0.7:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1491ms, Average = 372ms

C:\Users\P20120>arp -a

Interface: 10.0.0.10 --- 0xb
Internet Address Physical Address Type
10.0.0.7 00-11-32-15-a1-0e dynamic
10.0.0.255 ff-ff-ff-ff-ff-ff static
10.0.255.255 ff-ff-ff-ff-ff-ff static
224.0.0.252 01-00-5e-00-00-fc static
255.255.255.255 ff-ff-ff-ff-ff-ff static

C:\Users\P20120>
--------------------------------------------------------

Sieht also so aus, dass mein NAS wirklich aufgrund der ARP-Requests aus dem DeepStandby aufgeweckt wird !
Würde sich auch mit meiner am 3.1. beschriebenen Beobachtung mit dem Tool Wireshark decken. Da waren genau zu dem Zeitpunkt als das NAS aufwachte jeweils ein ARP-Request.


Die anderen Dinge kann ich erst wieder testen wenn ich Zuhause bin.

[zid]

hallo wolfgang,

>"...Interessanterweise sogar beim zweiten mal pingen wo die MAC eigentlich noch im Cache sein sollte..."
naja, ein ping soll den nas schon wecken, egal ob jetzt die einträge des arp cache aktuell oder flushed sind. interessanter wär dieser versuch mit arping, also irgendwas in der preisklasse:
> arping -b -c2 -Ieth0 10.0.0.7
dann gehen wirklich nur arp reqs raus...

lg
zid

[Sin10]

ich kann dir aufjedenfall sagen, das meine synology brav im deepsleep geht, auch wenn mehrere windows geräte im netzwerk sind und eine dreambox mittels nfs dauernd drauf ist.

Das ganze netzwerk wird bei mir allerdings von einem TG585v7 mit orginaler firmware+bereinigen config file betrieben (danke an dieser stelle an zid und co!). NAS, dreambox und mein rechner haben ne fixe IP adresse - der rest was im netzwerk rumspammt (tablets, handys, windows, fernseher - welcher auch zugriff hat, etc...) hat ne dyn ip.

aufwachen tut sie nur, wenn ich auf das netzlaufwerk zugreife - oder eben einen dienst benötige was sie bereit stellt, sei es via lan oder über das internet .

[zid]

hallo sin,

ich kann mich zwar nicht erinnern, jemals bei dir was verbrochen zu haben, und es freut mich natürlich sehr, daß bei dir alles wunschgemäß funkt, aber jetzt hätt ich schon 2 fragen:
1.
dein nas ist eine DS213+? bei *dem* ding scheints echt zoff zu geben mit dem deepsleep mode.
2.
die "bereinigte" ini- woher hast du die? aus den downloads von dieschmids, oder ist das eine meiner privaten inis, die ich öfters im hintergrund weitergegeben hab? bei denen ist nämlich der hostmgr idr. deaktiviert. was sagt:
=>hostmgr config

lg
zid

[Sin10]

hallo zid,

du hast bei mir direkt gar nix verbrochen - sondern ich selber durch eure tuts

1. zur nas: meine ist das vorgänger modell: eine DS212+ mit aktueller stable firmware von synology

2. nicht von dir, sondern direkt von eurer webseite "dieschmids" aus dem downloadbereich. Mit der orginalen firmware und dieser ini was es bei euch gibt, rennt das modem "rockstable" .. das ding hat bis jetz nicht einen einzigen absturz geliefert - einfach perfekt. Ich hatte das modem nämlich ganz anderst in erinnerung, und war oft bei leuten die probleme hatten mit dem ding, (reboots, hängen bleiben, usw. ..) jedoch war das immer mit der A1 firmware.

hier mal die ausgabe von
=>hostmgr config

Code: Alles auswählen

=>hostmgr config
  state    : enabled
  scantime : 30 sec.
  autosave : disabled
  trace    : enabled

=>

wie gesagt, meine NAS geht brav nach 10 min schlafen, wenn ich gerade nicht zugreife oder ein sonstiger dienst den schlafmodus verhindert.
Das ding dient bei mir ebenso als download station, welche aber nicht durch synology mitgeliefert werden

[wolfgang67]

@ zid:

Hätte gerade Deinen Tip mit dem "arping" versucht.
Leider kennt mein cmd diesen Befehl nicht

----------------------------
C:\Users\P20120>arp -d

C:\Users\P20120>arping -b -c2 -leth0 10.0.0.7
'arping' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\P20120>arping 10.0.0.7
'arping' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\P20120>

----------------------------

[wolfgang67]

@sin10:
Interessant, daß Du mit Syonolgy-NAS und Dreambox eine recht ähnliche Geräteliste hast. Ich hatte vorher auch ein "Speedtouch 585v6" im Einsatz. Nachdem ich bei meiner Dreambox 8000 auf die aktuelle Version 3.3.2 von NewNigma upgedatet hatte erkannte diese das Speedtouch nicht mehr. Darum habe ich dann auf das aktuelle Modem der Telekom eben das Pirelli gewechselt.

Hat Deine DS 212+ denn schon den DeepSleep-Modus ? Dachte der ist erst mit der 213+ eingeführt worden ?
Der normale Standby funktioniert bei meiner 213+ auch. Nach 60 sec. sollte sie aber in den DeepSleep-Modus gehen wo sie dann nochmal wesentlich weniger Strom verbraucht und auch der Lüfter nicht mehr läuft.

[zid]

JUUHUUU!! der hostmgr rennt, und die ds pennt...

hallo jungs,

sin,

zuerst mal vielen dank für deine rückmeldung. wir haben ein working system, und ich muß dich jetzt leider mit einer großen bitte echt nerven. es geht nämlich um folgendes:
1.
im ruhezustand muß die ds noch immer arp reqs beantworten, weil sie sonst nach ablauf des arp cache timeouts eines rechners von demselben nicht mehr geweckt werden könnte [1] (außer man setzt am rechner statische arp einträge, was aber nicht praktikabel ist. stell dir vor du hast 100 rechner im lan, da wirst narrisch).
2.
trotz beantwortung der arp reqs darf sie jedoch nicht aufwachen. das dürfte das prob vom wo67 sein.
soweit die graue theorie, mit einem praktischen beispiel täte sich der wo67 aber leichter, wenn er einen case bei synology eröffnen will.
das ganze könnte ca. so aussehen:

- du hängst einen kontrollrechner mit installiertem wireshark an den eth1 des tg.

- die ds hängt z.b. am eth4 des tg.

- du spiegelst den eth4 auf den eth1 mit:
=>eth switch mirror capture port 1
=>eth switch mirror ingress port 4
=>eth switch mirror egress port 4

- danach startest du den shark mit einem ansichtsfilter, sodaß du nicht durch irgendwelche nebengeräusche gestört wirst. angenommen das tg hat die (default) ip 10.0.0.138 und die ds hat die ip 10.0.0.129, dann schaut dieser filter so aus:

Code: Alles auswählen

(arp.opcode==0x0001&&arp.src.proto_ipv4==10.0.0.138&&arp.dst.proto_ipv4==10.0.0.129)||(arp.opcode==0x0002&&arp.src.proto_ipv4== 10.0.0.129&&arp.dst.proto_ipv4==10.0.0.138)

falls du andre ips verwendest, mußt du halt den filter sinngemäß anpassen. und der code-abschnitt ist natürlich ein einzeiler.

- danach siehst du nur den traffic hostmgr <-> ds. alle 30s (scantime=30) geht eine arp req vom hostmgr raus und wird von der ds beantwortet (in dem bunti unten kommen die reps nicht von einer ds, sondern von einem mikrotik. hab leider keine ds, sonst hätt ich mir eh schon alles angeschaut).

tg585v7_hostmgr_arp_traffic.png (36.34 KiB) 22443-mal betrachtet

- danach die trace als pcap sichern (und zwar nur die *displayed* packets!), und die pcap dem wo67 schicken.

bei unklarheiten fragen und vielen dank!


wolfgang,

wenn du schwein hast, dann zieht der sin unsren test von oben durch, und du schuldest ihm einen weißen spritzer + ein packerl tschicks...

insgesamt sollte der fahrplan klar sein:

- du prüfst die ganze gschicht noch mit arping
sry, hab vergessen, daß du win verwendest. arping muß da nachinstalliert werden:
http://www.heise.de/download/arping-1137383.html

- und wenn deine ds tatsächlich mit arp reqs geweckt werden kann, eröffnest du bei synology einen case, in dem du eben diesen sachverhalt darlegst. als vergleich verwendest du die ds212+ mit der gefilteten trace vom sin. dort funkt das zeugs ja offensichtlich.

diese problembeschreibung ist durch den vergleich ds213+ vs. ds212+ schon sehr aussagekräftig, sodaß eine begründete hoffnung besteht, daß dieser bug relativ rasch behoben wird.

solltest du wider erwarten deine ds mit arping nicht wecken können, dann liegt das prob woanders, und wir müssen weitersuchen.

>"...Hat Deine DS 212+ denn schon den DeepSleep-Modus ?..."
ich denke schon. der sin redet ja in seinem ersten post explizit davon:
"...ich kann dir aufjedenfall sagen, das meine synology brav im deepsleep geht..."

lg
zid


[1] //edit:
ich rede jetzt natürlich von ucasts, eh klar, oder?

[wolfgang67]

ich habe jetzt arping installiert und es nochmal versucht, bekomme aber immer die Meldung "arping: libnet_init(): libnet_select_device(): no network interface found" Die Option "leth0" wurde gar nicht angenommen.

---------------------------------
C:\Users\P20120>arp -d

C:\Users\P20120>arping -b -c2 10.0.0.7
arping: libnet_init(): libnet_select_device(): no network interface found

C:\Users\P20120>arping 10.0.0.7
arping: libnet_init(): libnet_select_device(): no network interface found

C:\Users\P20120>arping -0 10.0.0.7
arping: libnet_init(): libnet_select_device(): no network interface found

C:\Users\P20120>ping 10.0.0.7

Pinging 10.0.0.7 with 32 bytes of data:
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64
Reply from 10.0.0.7: bytes=32 time<1ms TTL=64

Ping statistics for 10.0.0.7:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\P20120>
---------------------------------

[zid]

mist, mist, mist...

hallo wolfgang,

du hast gleich 2 probs:
1.
der buchstabe vor dem eth0 ist kein kleines "l", sondern ein großes "I". der unabgekürzte befehl lautet *unter linux*:

Code: Alles auswählen

>arping -b -c 2 -I eth0 10.0.0.7

2.
unter win wird die syntax wahrscheinlich anders sein. versuch mal mit

Code: Alles auswählen

>arping -h
>arping --help
>arping ?

die korrekte syntax rauszufinden.
welches win rennt bei dir?
ich werd versuchen, eine win-kiste aufzutreiben, kann bis zum abend dauern.

lg
zid

[wolfgang67]

@zid: Grosses Danke für Deine Geduld !!!

Hier mein aktueller Auszug inkl. der Syntax bei der Windows-Version von arping in meinem Windows7.

------------------------------------------------
C:\Users\P20120>arping -b -c 2 -I eth0 10.0.0.7
arping: libnet_init(): libnet_open_link(): unable to open the driver, error Code
: 14


C:\Users\P20120>arping -h
ARPing 2.06, by Thomas Habets <[email protected]>
usage: arping [ -0aAbdFpqrRuv ] [ -w <us> ] [ -S <host/ip> ] [ -T <host/ip ]
[ -s <MAC> ] [ -t <MAC> ] [ -c <count> ] [ -i <interface> ]
<host/ip/MAC | -B>

Options:

-0 Use this option to ping with source IP address 0.0.0.0. Use this
when you haven't configured your interface yet. Note that this
may get the MAC-ping unanswered. This is an alias for -S
0.0.0.0.
-a Audiable ping.
-A Only count addresses matching requested address (This *WILL*
break most things you do. Only useful if you are arpinging many
hosts at once. See arping-scan-net.sh for an example).
-b Like -0 but source broadcast source address (255.255.255.255).
Note that this may get the arping unanswered since it's not nor-
mal behavior for a host.
-B Use instead of host if you want to address 255.255.255.255.
-c count
Only send count requests.
-d Find duplicate replies.
-F Don't try to be smart about the interface name. (even if this
switch is not given, -i overrides smartness.
-h Displays a help message and exits.
-i interface
Use the specified interface.
-q Does not display messages, except error messages.
-r Raw output: only the MAC/IP address is displayed for each reply.
-R Raw output: Like -r but shows "the other one", can be combined
with -r.
-s MAC Set source MAC address. You may need to use -p with this.
-S IP Like -b and -0 but with set source address. Note that this may
get the arping unanswered if the target does not have routing to
the IP. If you don't own the IP you are using, you may need to
turn on promiscious mode on the interface (with -p). With this
switch you can find out what IP-address a host has without tak-
ing an IP-address yourself.
-t MAC Set target MAC address to use when pinging IP address.
-T IP Use -T as target address when pinging MACs that won't respond to
a broadcast ping but perhaps to a directed broadcast.
Example:
To check the address of MAC-A, use knowledge of MAC-B and IP-B.
$ arping -S <IP-B> -s <MAC-B> -p <MAC-A>
-p Turn on promiscious mode on interface, use this if you don't
"own" the MAC address you are using.
-u Show index=received/sent instead of just index=received when
pinging MACs.
-v Verbose output. Use twice for more messages.
-w (arping 2.x only) Time to wait between pings, in microseconds.

C:\Users\P20120>
------------------------------------------------

[Aluminchen]

Hy,

-i interface

du musst statt einem grossen "i" ein kleines verwenden
Ausserdem wirst vermutlich statt dem "eth0" den Adapternamen
angeben müssen

Lg

[wolfgang67]

wo finde ich in meinem Windows7-System den Namen des Adapters ?