Unitymedia 6490 (lgi) - Magic Paket / Synology DS214Play

[mcxpert]

Guten Morgen,

als ich das Protokoll meiner Synology angeschaut hatte musste ich feststellen, dass diese jede Stunde aus dem Hibernation aufwacht (bsp 0:39 / 1:39 / 2:39 Uhr). Daraufhin habe ich so ziemlich alles versucht, da ich dachte irgendwein Dienst, Netzwerkteilnehmer oder oder sei die Ursache. Die Syno ohne Netzwerkkabel schläft die ganze Nacht durch.

Wlan an FB aus nur noch die Syno dran und sie hat obiges Verhalten. Ok dachte ich mache ich mal übergangsweise mit WOL und fahre die Syno komplett runter (also kein Hibernation) und zu meinem Erstaunen habe ich wieder stündliches Aufwachen.
Die Syno kann in ausgeschalteten Zustand NUR noch mit einem MagicPaket hochgefahren werden.

Daher die Frage, kann es sein das die FB stündlich so ein MagicPaket versendet???

Grüße Stephan.

 

[Conan179]

evtl. kannst du mal in der fritte nach shcauen, ob beim netzwerkgärt (deine nas) steht:
Wake on LAN
Mit der Funktion "Wake on LAN" können Sie einen Computer, der sich im Standby-Modus befindet, über das Netzwerk starten.
Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird.
Klicken Sie hier, um diesen Computer aus dem Standby-Modus zu starten (Wake On LAN).
ob das angehackt ist?

 

[tq1199]

Daher die Frage, kann es sein das die FB stündlich so ein MagicPaket versendet???

Das magic packet kann man mit einem capture filter feststellen/sniffen. Z. B.:

<i>
</i>sudo tcpdump -vvveni <Interface> ether proto 0x0842 or udp port 9

oder evtl. auch das Wake-on-lan mit Hilfe des magic packet, für das entsprechende Interface deaktivieren:

<i>
</i>:~$ sudo ethtool -s eth0 wol d

<i>
</i>:~$ sudo ethtool eth0 | grep -i wake	Supports Wake-on: g	Wake-on: d

EDIT:

Zum testen kannst Du das magic packet auch mit einem geeigneten tool, in deinem LAN gezielt (mit "-b" an die broadcast-Adresse oder nur an die MAC-Adresse) senden. Z. B.:

<i>
</i>sudo etherwake -i <Interface> -b <dst-MAC-Address>

 

[mcxpert]

@conan179: ja der hacken ist gesetzt aber erst nachdem ich keine andere lösung für das aufwachen finden konnte und dachte wenn ich sie herunterfahre bleibt sie auch aus. damit ich sie von unterwegs wecken kann muss ich das einschalten und udp9 freigeben. soll heissen, dass es auch vor diesem verändern schon das gleiche verhalten gegben hat.

@tq1199: wo sind die befehle auszuführen? auf der syno oder fb. Die fb ist bei unitymedia ja leider zu so das kein freez läuft. auf der syno hab ich unter dsm 6.1 immerhin schon root rechte wieder bekommen :smile:

edit: danke euch

 

[tq1199]

@tq1199: wo sind die befehle auszuführen? auf der syno oder fb. Die fb ist bei unitymedia ja leider zu so das kein freez läuft. auf der syno hab ich unter dsm 6.1 immerhin schon root rechte wieder bekommen :smile:

Zur Simulation könntest Du das magic packet von einem anderen Gerät aus deinem LAN, an die syno senden. Wenn die syno komplett runtergefahren ist, kannst Du auf dieser mit tcpdump logischerweise nicht sniffen.

Wenn Du das magic packet zum testen auch an die Broadcast-Adresse sendest, kannst Du tcpdump auf einem anderen Gerät in deinem LAN, sniffen lassen.

 

[mcxpert]

Hi,

hab das jetzt mal auf der Syno mit

sudo tcpdump -vvveni eth0 ether proto 0x0842 or udp port 9

laufen lassen. Ergebnis

20:41:05.788952 cc:ce:1e:a6:6d:50 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x0842), length 116: 0x0000: ffff ffff ffff 0011 3231 8c65 0011 3231 ........21.e..21 0x0010: 8c65 0011 3231 8c65 0011 3231 8c65 0011 .e..21.e..21.e.. 0x0020: 3231 8c65 0011 3231 8c65 0011 3231 8c65 21.e..21.e..21.e 0x0030: 0011 3231 8c65 0011 3231 8c65 0011 3231 ..21.e..21.e..21 0x0040: 8c65 0011 3231 8c65 0011 3231 8c65 0011 .e..21.e..21.e.. 0x0050: 3231 8c65 0011 3231 8c65 0011 3231 8c65 21.e..21.e..21.e 0x0060: 0011 3231 8c65

Dann über cmd mit arp -a die mac ermittelt und die passt zur Fritzbox.

Tolle Sache, heisst das jetzt (wie befürchtet), dass die Fritzbox MP versendet?

Würde

:~$ sudo ethtool -s eth0 wol d

verhindern, dass die Syno auf die Pakete reagiert?

 

[tq1199]

Würde

:~$ sudo ethtool -s eth0 wol d

verhindern, dass die Syno auf die Pakete reagiert?

Wie ist z. Zt. auf der Syno, die Ausgabe von:

<i>
</i>sudo ethtool eth0 | grep -i wake

(evtl. ohne sudo, wenn Du root bist)?

 

[mcxpert]

hi

login as: admin
[email protected]'s password:
admin@GaS_NAS_DS:~$ sudo ethtool eth0 | grep -i wake Supports Wake-on: umbg Wake-on: d

 

[tq1199]

<i>
</i> Wake-on: d

OK, und reagiert die Syno jetzt noch auf das magic packet?

 

[mcxpert]

Ja die reagiert noch aber wie gesagt ich hab auch noch keinen anderen Befehl ausgeführt der das so blocken würde.
Muss ich noch was eingeben in die Konsole oder was sagt jetzt die Aussage

Wake-on: d

 

[tq1199]

Muss ich noch was eingeben in die Konsole oder was sagt jetzt die Aussage

Wake-on: d

Die Aussage sagt, dass das Interface jetzt so konfiguriert ist, dass über dieses Interface "wake-on-lan" mit dem magic packet nicht mehr möglich sein soll.

Versuch mal auch, wenn möglich:

<i>
</i>sudo iptables -I INPUT 1 -p udp --dport 9 -j REJECT

auf der Syno.

 

[mcxpert]

da fehlt wohl was

<i>
</i>login as: admin
[email protected]'s password:
admin@GaS_NAS_DS:~$ sudo iptables -I INPUT 1 -p udp --dport 9 -j REJECT
iptables v1.6.0: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

hmm dann dachte ich versuch ich das mit dem filter inizialisieren mit diesem Ergebnis

admin@GaS_NAS_DS:~$ sudo -i
root@GaS_NAS_DS:~# cd /lib/modules
root@GaS_NAS_DS:/lib/modules# insmod nf_nat.ko
insmod: ERROR: could not insert module nf_nat.ko: Unknown symbol in module
root@GaS_NAS_DS:/lib/modules# insmod iptable_nat.ko
insmod: ERROR: could not insert module iptable_nat.ko: Unknown symbol in module
root@GaS_NAS_DS:/lib/modules# insmod ipt_REDIRECT.ko
insmod: ERROR: could not insert module ipt_REDIRECT.ko: Unknown symbol in module
root@GaS_NAS_DS:/lib/modules#

 

[Conan179]

@tq1199
eine frage hab ich an dich, funktioniert iptables auch im standby?

 

[tq1199]

@tq1199
eine frage hab ich an dich, funktioniert iptables auch im standby?

Nein, aber ich bin davon ausgegangen, dass:

<i>
</i>Wake-on: d

nicht funktioniert bzw. irgendwie ignoriert wird. Denn der TE schreibt ja, dass trotz "Wake-on: d" die Syno noch auf das "magic packet" reagiert.

Deshalb der Test im nicht standby, ob da evtl. noch was Anderes über den udp-Port 9 ankommt.

 

[mcxpert]

da man ja manchmal selbst an sich zweifelt hab ich heute nacht die syno vom ett0 abgezogen und heute morgen laut protokoll auch kein wakeup gehabt. war mir klar denn sie hat auch nicht geblinkt sondern war wirklich aus.

 

[tq1199]

... war mir klar denn sie hat auch nicht geblinkt sondern war wirklich aus.

Es ist so, dass das eth0-Interface deiner Syno nicht nur "wake on magic packet" unterstützt sondern auch:

<i>
</i>u Wake on unicast messages
m Wake on multicast messages
b Wake on broadcast messages

Was für Geräte hast Du evtl. noch 24/7, an deiner FB?

EDIT:

multicast und broadcast kannst Du sniffen, mit:

<i>
</i>sudo tcpdump -vvven "ether[0:2] & 0xff0f = 0x0100" or 'ether dst ff:ff:ff:ff:ff:ff and not arp'

 

[mcxpert]

ah ok

Es ist so, dass das eth0-Interface deiner Syno nicht nur "wake on magic packet" unterstützt sondern auch:

Code: Alles auswählen

u Wake on unicast messages
m Wake on multicast messages
b Wake on broadcast messages

das kann natürlich sein, dass es von sowas kommt, denn ich bezweifel langsam auch warum so viele MP versendet werden sollten.

Meine Tests gingen auch soweit, dass ich nur noch die Syno an der FB, WLAN abgeschaltet über nach laufen lies.
Ich habe sonst schon so einiges wie dreambox, smarttv, webradio, zwei repeater fritz...
daher habe ich es auch nur mit der beschriebenen direktverbindung syno fritz getestet.

Dann werde ich heute abend mal das andere sniffen und schauen was da noch so kommt.

Code: Alles auswählen

sudo tcpdump -vvven "ether[0:2] & 0xff0f = 0x0100" or 'ether dst ff:ff:ff:ff:ff:ff and not arp'

Dir, aber aber auch allen anderen, schon einmal ein extra dickes Dankeschön für die tolle Unterstützung :super:

 

[mcxpert]

kann man das auch gleich in eine datei schreiben lasse? sonst ist das ja im putty drin und ich muss es so raus kopieren

 

[Conan179]

las putty ein log direkt auf diene hdd schreiben mach ich immer
https://www.thomas-krenn.com/de/wiki/PuTTY_für_Logging_konfigurieren

 

[tq1199]

kann man das auch gleich in eine datei schreiben lasse?

Geht auch. Z. B.:

Schreiben in die Datei:

<i>
</i>sudo tcpdump -c 10 -vvven "ether[0:2] & 0xff0f = 0x0100" or 'ether dst ff:ff:ff:ff:ff:ff and not arp' -w ./tcpdump_w.txt

<i>
</i>:~$ file tcpdump_w.txt
tcpdump_w.txt: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 262144)

Lesen aus der Datei:

<i>
</i>sudo tcpdump -vvven -r ./tcpdump_w.txt

 

[mcxpert]

hab das

sudo tcpdump -vvven "ether[0:2] & 0xff0f = 0x0100" or 'ether dst ff:ff:ff:ff:ff:ff and not arp'

jetzt mal die nacht durchlaufen lassen und die stellen verglichen wo im syno protokoll das "aufwachen" protokolliert wurde. leider war hier kein eintrag dabei welcher dafür verantwortlich sein könnte.

kann man die ganzen pakete/protokolle auf der syno zum test abschalten?

Es ist so, dass das eth0-Interface deiner Syno nicht nur "wake on magic packet" unterstützt sondern auch:

Code: Alles auswählen

u Wake on unicast messages
m Wake on multicast messages
b Wake on broadcast messages

 

[tq1199]

.... leider war hier kein eintrag dabei welcher dafür verantwortlich sein könnte.

Evtl. kann das dafür verantwortliche Paket, von tcpdump gar nicht erfasst werden. Denn tcpdump snifft ja erst nach dem Interface. Was vom Interface verworfen wird bzw. am Interface schon verwertet/bearbeitet wird und somit nicht mehr weitergeleitet wird, kann von tcpdump nicht erfasst werden.

... kann man die ganzen pakete/protokolle auf der syno zum test abschalten?

Das sollte mit ethtool und "d":

<i>
</i>d Disable (wake on nothing). This option clears all previous options.

gehen, aber irgendwie funktioniert das auf deiner Syno (bzw. deren Interface) ja nicht.

 

[mcxpert]

ich glaube auch das meine syno das nicht unerstützt wenn ich die pakete zulassen wollte bekomme ich die ausgabe zurück

root@GaS_NAS_DS:~# sudo ethtool -s eth0 wol p
Cannot set new wake-on-lan settings: Operation not supported
not setting wol

ich weis so langsam echt nicht mehr weiter. es kann auch nur an der dsm verison liegen denn ich habe protokolle von version 5 und da schläft alles mit gleicher konfig.
bin jetzt echt am überlegen ob ich sie dauerhaft laufen lasse denn mein disk spinning ist schon über 8500 und hiervon alleine in diesem jahr 5000(!).
Für die HDDs (WD RED 2TB) ist das ja nicht gesund zumindest lese ich oft davon oder was ist hier eure Erfahrung?

 

[johnripper]

Was meinst du mit

disk spinning

?

Die WD Reds sind für den Dauerbetrieb also 24/7 ausglegt und lt. Datenblatt können Sie 600k Lade-/Entladezyklen ab.

 

[mcxpert]

Was meinst du mit

disk spinning

?

Die WD Reds sind für den Dauerbetrieb also 24/7 ausglegt und lt. Datenblatt können Sie 600k Lade-/Entladezyklen ab.

nicht das was ich sagen wollte
es sollte start_stop_count heissen und somit das anlaufen der hdd's