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

[wolfgang67]

Hallo Zid !

Danke für Deine wirklich ausführliche und sehr verständlicher Erklärung !
Damit wird mir manches noch klarer.

Bei mir ist derezti die Situation so, dass der Router die Diskstation nie mehr aufweckt. Damit bleibt sie auch aus wenn ich nicht arbeite. Wenn ich den Laoptop im Netz habe ist es oft recht unterschiedlich. Manchmal bleibt sie lange im System Standby, machmal wacht sie recht oft wieder auf. Hab etwas den Eindruck dass wenn Sie mal aufgeweckt wurde dann regelmäßig aufgewckt wird.

Einmal hatte ich interessanterweise die Situation, dass die DS durch einen Zugriff vom Laptop aus nicht mehr aufgewacht ist. Hab dann kurz zum Handy gegriffen und das Photo-App. gestartet. Durch diesen Zugriff ist die DS dann aufgewacht.

Die einzige sinnvolle Lösung wäre wohl wenn die DiskStation ARP-Requests beantworten könnte ohne dabei aus den SystemStandby aufzuwachen. Dass müsste sie dann mit ihrem wach bleibenden Rest machen. Ist natürlich fraglich, ob sowas durch ein Firmware-Update gelöst werden kann.

Liebe Grüße
Wolfgang

[Benoki]

Hallo,

sorry, dass ich so einen alten Thread wieder aufgreifen muss. Ich habe aber das selbe Problem!
Mein Pirelli lässt meine neue Synology DS413 nicht in den Deepsleep gehen. Wie der TE hier schon erklärt hat.
Ich habe dann jetzt den Hostmanager deaktiviert (LAN-Bridge auf 'Deaktiviert'), die NAS wird aber trotzdem aufgeweckt.

Das mit dem Telnet habe ich leider nicht ganz verstanden.
Telnet-Client ist als Windows-Feature installiert - wenn ich bspw. 'telnet 10.0.0.138' eingebe, kommt kurz ein cmd Fenster, welches gleich wieder zu geht. Wie soll ich da die zwei Befehle eingeben?
Firmware ist 5.3.5. Mit welcher Firmware geht das?

Über Hilfe wäre ich extrem dankbar. Ich bin echt ratlos.

Dankeschön und schönes Wochenende,
Benoki

[wicked_one]

du musst zuerst das schwarze Fenster (die Eingabeaufforderung) an sich öffnen... und dann dort reinschreiben.

[Benoki]

Hab ich erleidgt. Musste zuerst die Firmware downgraden. Mit der neuen ging nix.
So, die Befehle über Telnet habe ich eingegeben.

Meine NAS geht immer noch nicht schlafen.
Bin Ratlos. Dann hab ich noch DNS Probleme mit A1... wird immer schlimmer.
Tja, wird wohl Zeit zum Anbiter wechseln.

[zid]

hallo benoki,

die diskussion mim wolfgang bezog sich auf die r5.1.6 des pires, bei der 5.3.5er wirds eng, weil sie gesperrt ist.
aber der reihe nach:

1. bei der 5.3.5er bringt dir telnet/ssh nix,...
...weil die sw. gesperrt ist. hast du eh schon bemerkt...

2. es genügt nicht, nur den hostmgr zu deaktivieren
wenn du hier nachliest:
viewtopic.php?f=20&t=54426&#p449458
dann siehst du, daß der wolfgang den gesamten unnötigen plunder, der im ta-default am pire aktiv ist, deaktiviert hat.

3. durch den deep sleep mode ist dein system/netz weder robust noch skalierbar
die syno kann nicht nur vom zugangsrouter, sondern von jedem gerät im lan geweckt werden.
angenommen du schaffst es irgendwie, *alle* geräte in deinem lan so hinzubiegen, daß die syno nicht geweckt wird. ja, und dann brauchst du eines tages auf irgendeinem spielzeug irgendein feature. du aktivierst es, und auf einmal wird die syno von dem feature geweckt. kleine änderung mit großer wirkung also und somit ein nicht robustes system.
nächstes szenario:
man gönnt sich ja normalerweise nix, aber manchmal tut man sich doch was gutes und kauft sich ein neues spielzeug. du hängst es ins lan, und das ding weckt die syno auf. ok, kein prob, den kritischen dienst auf dem neuen spielzeug hamma gleich, nur mal den shark anwerfen und fertig. du findest den kritischen dienst dann auch, stellst allerdings nach ein paar tagen recherche mit bedauern fest, daß man ihn gar nicht deaktivieren kann, oder das gerät wird wertlos, wenn das störende feature deaktiviert wird...
d.h. du kannst dein netzwerk gar nicht so ohne weiters vergrößern, sondern mußt dich vor dem kauf *im detail* schlau machen, was auf dem neuen gerät so alles kreucht und fleucht und ob man das zeugs notfalls auch deaktivieren kann. ingesamt ein handfestes skalierungsprob...
deshalb ist aus meiner sicht der verzicht auf den deep sleep mode und die verwendung von wol durchaus eine überlegung wert. du mußt die nic mit ethtool so konfigurieren, daß sie wirklich nur auf magic packets reagiert, also:

Code: Alles auswählen

# ethtool -s <nic-name-syno> wol g

und schon fertig. es ist klar, daß dieser ansatz auch seinen preis hat. nach dem wecken der syno wird der ganze bootporzeß durchlaufen, und das ding ist nicht so schnell da, wie wenn du es aus dem deep sleep wecken würdest. da reden wir aber nur über sekunden, und wenn die nicht drinn sind, dann dreh die syno erst gar nicht ab.

4. du kannst dir was gutes tun...
die sw. des pires ist- egal ob offen, gesperrt, wwi- schlecht, punkt. schadet der schönheit, dem zarten nervenkostüm und senkt die lebenserwartung deutlich.
du erleichterst dir das leben, wenn du diese hoffnungslose gurke auf su drehst und mit einem nachgeschalteten spielzeug, das die bezeichnung "router" verdient, einwählst.
geeignete geräte sind imho alle router auf basis openwrt (die tp links erfreuen sich bei den leuten aktuell ziemlich beliebtheit z.b.) oder routeros (mikrotik z.b.).

>"...Tja, wird wohl Zeit zum Anbiter wechseln..."
nana, so dramatisch isses jetzt auch wieder nicht. dein prob kann auch hausgemacht sein -> s. #2 und #3.
wenn die syno durch ein gerät in deinem lan geweckt wird, bringt dir ein providerwechsel genau nüsse...

lg
zid

[Benoki]

Hi,

danke für deine Antwort. Hab jetzt alles genannte deaktiviert und werde berichten.
Ich hab zwar noch einen Rangemax hier, unterstützt aber leider kein PPPoA. Und ich habe echt keine Lust, mir einen neuen Router zu kaufen, den ich eigentlich nicht benötige. Habe hier vor einem Jahr alles neu verkabelt, WLAN brauche ich daher kaum (Laptop und Smartphone, für das reicht mir das Pirelli). Ich würde ja gerne meinen vorhandenen Rangemax einsetzen, geht aber nicht. DD-RWT wird leider auch nicht unterstützt.

Das mit dem Providerwechsel hängt mit meinen DNS Problemen zusammen, die ich schon seit langer Zeit habe.

Liebe Grüße

EDIT:
Nun geht mein NAS nicht mal mehr in den HDD-Ruhemodus...
Ich sags dir, irgendwann verbrenn ich das Modem

[zid]

hallo benoki,

>"...unterstützt aber leider kein PPPoA..."
naja, mit pppoa direkt wirds halt a bizzi eng, weil das pire und der rangemax keine atm-schnittstellen haben. bei adsl erfolgt die einwahl über pptp, um eben das atm auf der strecke dialer <-> modem (pire) zu umgehen. dein rangemax (welcher genau btw.?) muß also nur einen pptp-client haben.
trotzdem ist der zugangsrouter nur die halbe miete. der wolfgang hat am pire alles abgedreht, und dennoch wurde die syno manchmal geweckt- von irgendeinem rechner im lan... wie gesagt, du mußt *alle* geräte im lan checken.

>"...Das mit dem Providerwechsel hängt mit meinen DNS Problemen zusammen, die ich schon seit langer Zeit habe..."
um welche dns-probs gehts da genau? wirklich nachhaltige probs mit dns sind mir bei der ta nicht bekannt.
bei manchen fw.'s des pires gibts zoff mit dem *lokalen* dns (i.e. wenn der resolver des pires z.b. für ntp oder dyndns namensauflösungen sucht), was dann zur folge hat, daß der ntp- und der ddns-client net funken. dieses "vergnügen" hatte ich grad vor 2, 3 tagen bei einem user mit einem pire und der r2530er.
workaround für diese spezialsituation:
- man setzt beim ntp-client keinen pool (at.pool.ntp.org z.b.), sondern ips für (2) timeserver (131.130.1.[11-12], uni wien).
- man setzt statische hosteinträge für den server des ddns-provider (member.dyndns.org = 204.13.248.111,
dynupdate.no-ip.com = 8.23.224.120 usw.).

lg
zid

[zid]

>"...Ich sags dir, irgendwann verbrenn ich das Modem..."
hihi, die variante kenn ich noch gar nicht. ich hau die dinger immer auf die müllhalde...
don't panic, mein lieber...

lg
zid

[Benoki]

Hi,

ich weiß nicht, was ich sagen soll...
Ich habe den ganzen Tag herumexperimentiert, alles mögliche abgeschaltet und so weiter und so fort.
Was ich sagen kann - das NAS SCHLÄFT!
Keine Ahnung, was ich gemacht habe. Alles mögliche im Modem deaktiviert was du gesagt hast, noch ein paar andere Dinge geändert, bei dem NAS Zeitsynchronisation und E-Mail bei Problemen abgeschaltet, und so weiter. Auf jeden Fall macht das NAS nun was es soll. Sehr schön.

Danke vielmals für die Hilfe!

Was das DNS Problem angeht.. mit den A1-DNS habe ich extreme Probleme. Ich komme nicht ins Internet raus, oder nur Teilweise (extrem langsam, ab und zu komme ich einmal kurz durch bei einer Seite aber extreeeeeem langsam). Auch die Business-DNS von A1 sind sehr langsam. WLAN-Geräte lässt das Modem gar nicht mehr raus. Habe nun bei allen Geräten den Google-DNS (8.8.8.8 und 8.8.4.4) eingestellt und der läuft Prima. Das kanns einfach nicht sein. Dazu muss ich jeden Tag mal das Modem neustarten weil's einfach spinnt. Das mit dem DNS kann ja wohl kein Modem-Problem sein, oder?
Und wenn ich mein Modem tauschen lassen KANN dann nur mit einer weiteren Jahres-Bindung, welche ich nun nach gut 10 Jahren bei der Telekom/A1 sicher nicht eingehen werde, in der letzten Zeit häufen sich die Probleme.

Gruß

PS: Es handelt sich um einen Netgear Rangemax WPN824 v2 Router. Bisschen älter, aber immer noch besser als der Pirelli-Müll

[zid]

hm, interessant, daß die leute so auf penner stehen...

hallo benoki,

>"...Keine Ahnung, was ich gemacht habe..."
schade. eine zusammenfassung deiner erkenntnisse wär für andre synology user sicher interessant gewesen...

zum dns:
>"...Das kanns einfach nicht sein..."
naja, soo langsam sind die server der ta jetzt auch wieder nicht. hier die 2 server von den bia's (213.33.90.70, 80.120.17.70) im vergleich zu google (8.8.8.8 ):

Code: Alles auswählen

$ dig xdsl.at @213.33.99.70
...
;; ANSWER SECTION:
xdsl.at.      7200   IN   A   91.237.143.222
...
;; Query time: 31 msec
;; SERVER: 213.33.99.70#53(213.33.99.70)
...

$ dig xdsl.at @80.120.17.70
...
;; ANSWER SECTION:
xdsl.at.      7200   IN   A   91.237.143.222
...
;; Query time: 30 msec
;; SERVER: 80.120.17.70#53(80.120.17.70)
...

$ dig xdsl.at @8.8.8.8
...
;; ANSWER SECTION:
xdsl.at.      2461   IN   A   91.237.143.222
...
;; Query time: 39 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

ok, der server von google antwortet jetzt um rd. 25% langsamer, was plausibel ist. wir reden hier aber über zeitliche größenordnungen, die unter der wahrnehmungsgrenze liegen. ein paar hunderstel +/- bei der namensauflösung kannst du nicht mal dann wahrnehmen, wenn du einen "sehr schnellen" blick hast. und außerdem spielen da noch weit schwerwiegendere faktoren rein: caching verhalten des browsers, leistungsfähigkeit, belastung und anbindung des servers, der die angeforderte seite hostet, cpe...

>"...Das mit dem DNS kann ja wohl kein Modem-Problem sein, oder?..."
hm, glaub ich jetzt auch nicht, aber beim pire is nix fix... umgekehrt muß man in dem fall nicht spekulieren, weil man einfach nachschauen kann.

1. du startest am pire eine shell und wirfst tcpdump an:

Code: Alles auswählen

> telnet 10.0.0.138
OpenRG> system shell
/ # tcpdump -nttt -i ppp0 'udp port 53'
tcpdump: listening on ppp0

durch die option "ttt" wird bei jedem paket die zeitdifferenz (in µs) zum vorangegangenen paket angegeben, sodaß du nicht rechnen mußt. die zeitdifferenz, die du mit tcpdump mißt, is ein maß für die schnelligkeit des verwendeten dns-servers (tcpdump erfaßt rausgehende pakete sehr spät und reinkommende sehr früh).

2. du installierst auf einem rechner den wireshark und startest ihn mit dem capture filter "udp port 53" (der capture filter ist nicht der ansichtsfilter, beim capture filter gilt die syntax von tcpdump). schaut so aus:

wshark_cfilter_udp_53.png (94.74 KiB) 18223-mal betrachtet

wenn der shark rennt, stellst du unter View > Time Display Format das anzeigeformat der zeiten ein ->
"Seconds Since Previous Captured Packet".

4. du checkst z.b. mit dig die zu vergleichenden dns-server durch, z.b.

Code: Alles auswählen

$ dig xdsl.at @213.33.99.70
...
$ dig xdsl.at @8.8.8.8

5. bei den ergebnissen gibts 2 möglichkeiten:

i. die zeitdifferenzen von tcpdump und wshark sind praktisch gleich:
wenn sie dann auch noch niedrig sind (i.e. < 100 ms), dann gibts überhaupt kein prob. wenn sie jedoch hoch sind, dann gibts zoff mit dem verwendeten dns-server.

ii. die zeitdifferenzen von tcpdump und wshark sind verschieden, oder es kommt am rechner überhaupt nix rein.
dann liegt das prob beim pire.

6. ein kleines beispiel zur veranschaulichung:
ich checke den 213.33.99.70.

Code: Alles auswählen

$ dig xdsl.at @213.33.99.70
...
...
;; Query time: 26 msec
;; SERVER: 213.33.99.70#53(213.33.99.70)

am pire sieht diese anfrage dann so aus:

Code: Alles auswählen

/ # tcpdump -nttt -i ppp0 'udp port 53'
tcpdump: listening on ppp0
000000 *.*.*.*.1025 > 213.33.99.70.53: ...
024923 213.33.99.70.53 > 10.0.0.145.1025: ...


knapp 25 ms also. und das ergebnis am shark is praktisch gleich:

wshark_dns_timing.png (17.34 KiB) 18223-mal betrachtet

unterm strich somit alles paletti.

bei hartnäckigen dns-probs ist es keine schlechte idee, einen lokalen dns forwarder/resolver zu verwenden, weil die dinger cachen. hier als beispiel ein cisco 887va (ip 10.0.0.132):

- ich lösche den cache und führe danach eine dns-abfrage durch:

Code: Alles auswählen

Rou88#clear host view data *

$ dig xdsl.at @10.0.0.132
...
...
;; Query time: 31 msec
;; SERVER: 10.0.0.132#53(10.0.0.132)

- durch die abfrage enthält der cache des cisc einen eintrag für xDSL.at, und die nächste abfrage geht schneller:

Code: Alles auswählen

Rou88#s host all | i xdsl
xdsl.at                   None  (temp, OK)  0   IP    91.237.143.222

$ dig xdsl.at @10.0.0.132
...
...
;; Query time: 3 msec
;; SERVER: 10.0.0.132#53(10.0.0.132)

ok, zugegeben, eine reduktion der abfragezeiten von 30 auf 3 ms wird man jetzt nicht wirklich wahrnehmen (s. a. weiter oben). wenn man aber aus irgendwelchen gründen mit abfragezeiten von ein paar hundert ms konfrontiert ist und die dann auf ein paar ms runterdrücken kann, dann merkt man das schon.


>"...Dazu muss ich jeden Tag mal das Modem neustarten weil's einfach spinnt..."
fürchte, daß du ein prob mit der verbindungsverwaltung des pires und net mit dns hast.
der user, dessen pire die probs mit den lokalen dns requests hat (s. mein vorletzter post), hat ein ähnliches prob: das internet wird mit zunehmender betriebszeit immer langsamer und pendelt sich dann irgendwann auf das niveau eines 56k modems ein. a bizzi wenig für gs16... und *das* hat sicher nix mit dns zu tun.
aktuelle abhilfe bei ihm wie bei dir neustart. gut, da werden wir uns noch was überlegen müssen...

>"...Es handelt sich um einen Netgear Rangemax WPN824 v2..."
das ding kann pptp. details s. reference guide s. 3-11, fig. 3-7:
http://www.downloads.netgear.com/files/ ... manual.pdf

lg
zid

[Benoki]

Hi,

hab heute in der Firma 2 Kunden gehabt mit dem Pirelli-Müll die GENAU das gleiche Problem haben.
Ergo -> A1 soll mir ein neues senden. Wenn das kein Einzelfall ist, mach ich mir echt nicht die Mühe das ganze ausgiebig zu testen, dazu fehlt mir einfach die Zeit... ein Kunde meinte, der hätte ein neueres Pirelli bekommen und das I-Net läuft wieder. Das werde ich auch versuchen. Wahrscheinlich kann ich das ganze Spiel mit dem NAS dann noch mal machen

GS16? Nene, soviel geht hier nicht, 8 Mbit/s ist maximum hier.

Die Zusammenfassung lautet wie folgt:
-> Deine Tips (Hostmgr deaktivieren und den ganzen anderen Kack auch).
-> Beim NAS Zeitsynchronisation ausgeschaltet u. manuell die Zeit eingetragen
-> Benachrichtungs - E-Mails ausschalten beim NAS (kam ab und zu ein Fehler, weiß nicht inwiefern das zusammen hängt)
-> Keine Pakete installiert

Jo, ich denke das wars. Musste beim NAS auch zuerst den DNS umstellen.

Gruß und DANKE für deine ausführlichen Anleitungen

[zid]

es geht nix über eine schöne zusammenfassung...

hallo benoki,

hab mir schon ein lesezeichen gesetzt, und wenn der nächste user mit probs beim deep sleep mode aufkreuzt, dann leg ich ihm den benoki'schen ansatz ans herz...

>"...Wahrscheinlich kann ich das ganze Spiel mit dem NAS dann noch mal machen..."
ich weiß zwar nicht mit welcher fw. die pires dzt. ausgeliefert werden, du kannst aber davon ausgehen, daß sie gesperrt ist. d.h. du kannst deinen ansatz nicht durchziehen.
mögliche workarounds (ohne anspruch auf vollständigkeit):

- du drehst die gesperrte fw. auf su und schaltest deinen gear als pptp-dialer nach. fraglich ist, ob du die konfig des gear so hinbiegen kannst, daß dein nas nicht gestört wird. mußt du halt ausprobieren...

- ein tg788er wär auch eine option. fw. ebenfalls gesperrt, su jedoch möglich. und das ding rennt auf alle fälle stabiler als das pire.

- da du gsd. noch adsl hast, bist du bei der wahl des cpe nicht so eingeschränkt wie bei vdsl. du könntest also ein st546v6 oder tg585v7 andenken. die dinger werden einem heutzutage um ein paar euro nachgeschmissen, sind extrem flexibel von der konfigurierbarkeit her gesehen und laufen selbst auf grenzwertigen leitungen stabil. vorsicht bei einkäufen in der bucht, wenn der verkäufer aus .de kommt. in dem fall ist das gerät ziemlich sicher annex b. du hingegegen brauchst *annex a*.
eine geeignete ini könnt ich dir bei bedarf zukommen lassen.

- der phantasie sind keine grenzen gesetzt...

lg
zid

[cybertron]

ich habe dass synology ds212j hatte selbige probs,seit ich anderen router benutze,keine Probleme mehr