Wake-on-LAN will einfach nicht

[BLU1312]

Hallo,

ich hatte meine Frage zunächst im Netzwerkforum gepostet, da ich gehofft habe, ich könnte das WoL vielleicht durch eine andere Netzwerkkarte zum Laufen bekommen. Daraufhin wurde mir geraten, meine Frage im Linux-Bereich zu posten. Ich hoffe, ihr könnt mir helfen.

Ich habe einen Dell T30 mit OpenMediaVault (auf Debian-Basis), der als Server läuft, aber eben nicht immer. Den möchte ich über WoL aufwecken, wenn ich ihn benötige.

Hierzu habe ich die Dell-Anleitung https://www.dell.com/support/kbdoc/... System neu,Option, die Sie verwenden möchten befolgt:

• im BIOS Deep Sleep deaktiviert
• Wake-on-LAN per LAN aktiviert
• Die Netzwerkkarte habe ich per "Magic Packet Activity" aufweckbar gemacht. Der Befehl *******@myserver:~# ethtool enp12345 | grep Wake-on liefert mir folgende Ausgabe:

Supports Wake-on: pumbg
Wake-on: g

Aufzuwecken versucht habe ich den Server über wol.exe (von einem Windows-PC aus) mit den Parametern IP, IP und MAC-Adresse, MAC-Adresse.

An der Netzwerkkarte blinkt die gelbe LED, wenn ich ihn über shutdown -h now herunterfahre.

Habt ihr eine Idee, was ich machen kann/muss, um das zum Laufen zu bekommen? Dann könnte der Server endlich in den Serverschrank im Keller wandern, was ich bisher gescheut habe, da ich sonst jedes Mal in den Keller muss, um ihn anzuschalten.

Vielen Dank!

 

[Mickey Mouse]

MAC ist richtig?
Windows Rechner befindet sich auch im selben physikalischen Netzwerk? Also nicht z.B. Windows-PC WLAN und Linux Kiste im LAN?

ich hatte auch schon Fälle (gerade nach viel "herum spielen" um WoL zum fliegen zu bekommen ), dass sich da wohl einige Bits so verklemmt hatten, dass erst ein "richtiges" Stromkabel ziehen (>30s) geholfen hat, nach einem "normalen" reboot oder shutdown ging es immer noch nicht.

 

[BLU1312]

Danke für deine Antwort.

Das ganze geht ja schon etwas länger bei mir. Ich bilde mir ein, dass ich es auch schon von einem PC im gleichen LAN probiert habe. Mit einem Laptop im WLAN und dem Server immer im LAN habe ich es auf jeden Fall probiert. Ich komme aber auch mit dem Laptop per WinSCP auf den Rechner. Ich werde es aber morgen vom LAN aus nochmal probieren.

Wie genau hast du nach dem Steckerziehen denn dann weitergemacht? Nur den Stecker gezogen, wieder eingesteckt und dann das Aufwecken durchgeführt oder den Rechner danach gestartet, nochmal heruntergefahren und dann aufgeweckt?

 

[BLU1312]

Ich habe den Server jetzt mal von einem, im LAN und am selben Switch hängenden Rechner aus "aufgeweckt". Er blieb aber aus. Den Stecker hatte ich auch gezogen und das dann erneut versucht. Wieder ohne Erfolg.

Also wol-Kommando nutze ich folgendes:

wol.exe 12-3A-4B-C5-D6-EF
WOL.exe 2.1 - Wake-On-LAN Utility - www.Gammadyne.com
Copyright (C) 2000-2017 by Greg Wittmeyer - All Rights Reserved

Wake-up packet sent successfully.

Ich weiß nicht, ob das wichtig / interessant ist, aber die IP ist nicht bekannt, während der Server aus ist. Da kommt dann die Meldung

No internal networking adapter has the IP address 10.50.50.10

 

[Dassie]

Wie hast du die Netzwerkkarten den aufweckbar gemacht?
ethtool -s enp12345 wol g
Geht nämlich nach einem Reboot wieder verloren.

 

[BFF]

Das das Tool sagt das es das Paket (WOL) gesendet hat hat nix damit zu tun das das Teil mit der MAC das auch empfangen hat bzw. ueberhaupt darauf reagiert. @BLU1312

Zusaetzlich noch dazu. Nicht jedes "Tool" macht auch wirklich alles richtig.
Was heisst, dass Du ruhig auch ein anderes Tool nutzen kannst um das WOL zu senden.

 

[karhu]

Hast du in den aufweckenden Maschinen mehrere Netzwerk-Interfaces? Versuch mal entweder ein Interface mitzugeben (z.B. etherwake -i) oder via IP zu wecken - alternativ zur IP kannst du auch die Broadcast Adresse deines Netzes mal ausprobieren (also z.B. 192.168.178.255 wenn dein Netz 192.168.178.0/24 ist).

 

[Dassie]

No internal networking adapter has the IP address 10.50.50.10
Das bedeutet doch die IP ist nicht bekannt und somit ist es auch nicht möglich über die IP aufzuwecken.
Über die MAC müsste es gehen.

 

[BLU1312]

Guten Morgen und vielen Dank für eure Antworten.

Wie hast du die Netzwerkkarten den aufweckbar gemacht?
ethtool -s enp12345 wol g
Geht nämlich nach einem Reboot wieder verloren.

Ich weiß es nicht mehr, um ehrlich zu sein. Was ich aber eben nochmal getestet habe: Wenn ich den Server hochfahre und dann auf der Shell ethtool enp12345 | grep Wake-on ausführe, dann kommt die Ausgabe
Supports Wake-on: pumbg
Wake-on: g
Ich kann mich noch grob erinnern, dass ich auch gelesen hatte, dass das wol g "flüchtig" sei und dass man es irgendwie anders konfigurieren muss, aber nicht mehr, wie (ich bin schon länger am Rumprobieren, dass das endlich mal funktioniert).

Das das Tool sagt das es das Paket (WOL) gesendet hat hat nix damit zu tun das das Teil mit der MAC das auch empfangen hat bzw. ueberhaupt darauf reagiert. @BLU1312

Zusaetzlich noch dazu. Nicht jedes "Tool" macht auch wirklich alles richtig.
Was heisst, dass Du ruhig auch ein anderes Tool nutzen kannst um das WOL zu senden.

Dass das erfolgreiche Senden nur bedeutet, dass irgendwas syntaktisch korrektes verschickt wurde und nicht, dass es irgnedwo angekommen ist / etwas ausgelöst hat, war mir bewusst.

Ih habe MagicPacket probiert, das rein über die MAC-Adresse funktioniert und WOL - Magic Packet Sender. Mit beiden war es aber leider auch nicht erfolgreich.

Hast du in den aufweckenden Maschinen mehrere Netzwerk-Interfaces? Versuch mal entweder ein Interface mitzugeben (z.B. etherwake -i) oder via IP zu wecken - alternativ zur IP kannst du auch die Broadcast Adresse deines Netzes mal ausprobieren (also z.B. 192.168.178.255 wenn dein Netz 192.168.178.0/24 ist).

Ich habe nur einen Netzwerkanschluss hinten am Gehäuse. Laut ifconfig (siehe unten) sind aber mehrere konfiguriert, u.a. für Docker, aber nur eine hat eine echte IP, etc. zugeordnet.
Ich habe es sowohl via wol.exe 10.50.50.255 (was meiner Konfiguration entsprechen sollte), als auch wol.exe 10.50.50.0/24 probiert. Beides hat leider keinen Erfolg gebracht.

No internal networking adapter has the IP address 10.50.50.10
Das bedeutet doch die IP ist nicht bekannt und somit ist es auch nicht möglich über die IP aufzuwecken.
Über die MAC müsste es gehen.

Genau. Das wollte ich nur der vollständigkeithalber posten. Nicht, dass irgendwann dann rauskommt, dass die IP ja gar nicht bekannt ist und es deshalb gar nicht gehen kann.

---------------------
Noch ein paar Infos, vielleicht sind die auch Ausschlaggebend: Ich nutze OpenWrt auf meinem Router, der ab einem gewissen Punkt auch als Switch dient. Kann der solche Aufrufe vielleicht herausfischen?

Heruntergefahren wird der Server per shutdown -h now (oder über dessen Weboberfläche mit "herunterfahren" (ohne zu wissen, was da genau im Hintergrund für ein Befehl verwendet wird). Ein systemctl suspend macht das Aufwecken aber auch nicht möglich.

Ich poste auch mal meine ifconfig-Ausgabe vom Server, nur um sicherzugehen, dass ich auch wirklich den richtigen Adapter nehme (wobei ich mir zu 99,9% sicher bin, da dies der einzige mit der IP meines Netzwerks ist; die Fettgedruckte ist die, die ich verwende):

docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 ee91::53:fffe:ef12:1234 prefixlen 64 scopeid 0x20<link>
ether 16:18:fe:00:12:34 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 101 bytes 33783 (32.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

enp12345: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.50.50.10 netmask 255.255.255.0 broadcast 10.50.50.255
inet6 fe19:1234:5678:9:1011:1213:1415:1617 prefixlen 64 scopeid 0x0<global>
inet6 fe80::4a4d:7eff:fed3:e8ae prefixlen 64 scopeid 0x20<link>
ether 12:34:56:78:91:01 txqueuelen 1000 (Ethernet)
RX packets 1410 bytes 317545 (310.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5308 bytes 7322095 (6.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xdf100000-df120000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 374 bytes 99661 (97.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 374 bytes 99661 (97.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth00000: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::ab12:8ff:febc:2ff7 prefixlen 64 scopeid 0x20<link>
ether fe:13:17:ef:2b:f7 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 118 bytes 44598 (43.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth222222: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe70::3ab3:33ff:fe9a:bd2 prefixlen 64 scopeid 0x20<link>
ether 3e:c2:24:9a:3b:d2 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 124 bytes 46238 (45.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth888888: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 ff70::12ef:34ee:be48:123a prefixlen 64 scopeid 0x20<link>
ether 89:ef:12:32:19:2a txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 120 bytes 45844 (44.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

vethb1111111: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::cce8:d5ee:fe40:7e8e prefixlen 64 scopeid 0x20<link>
ether de:f1:e3:12:8e:9d txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 120 bytes 45839 (44.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

vethf0000000: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe12::3456:e8ee:kf12:d40b prefixlen 64 scopeid 0x20<link>
ether 86:12:e5:56:k7:0a txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 122 bytes 44981 (43.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

 

[h00bi]

Grundsätzlich gibt es sehr viel Software, die keine sauberen WOL Pakete verschickt.
Aus Windows heraus würde ich dir "Magic Packet" empfehlen.
https://www.marcengbarth.com/programme/magicpacket/

Wenn dieses Tool nicht geht, dann ist es ein WoL Config Problem am zu weckenden Host.
Schließe erstmal den "Wecker" als Fehlerquelle aus.

Ich weiß nicht, ob das wichtig / interessant ist, aber die IP ist nicht bekannt, während der Server aus ist.

Das ist eigentlich nicht wichtig.
Ein echtes, sauberes Magic Packet wird an die Broadcast Adresse geschickt, nicht an die Client IP.
Die WoL aktivierte Netzwerkkarte lauscht auf einen Broadcast, der an die eigene MAC adressiert ist.

Das oben verlinkte Tool fragt die IP nur ab, um die Broadcast Adresse zu ermitteln.

 

[BLU1312]

Vielen Dank für deine Antwort.

MagicPacket hatte ich heute Mittag ausprobiert. Damit hat es auch nicht funktioniert.

Kann ich denn in irgendwelchen Logs sehen, ob beim Runterfahren das "Wake-on g" noch aktiv ist, oder in irgendwelchen Logs, ob vielleicht ein Paket ankam, das Hochfahren versucht wurde, aber fehlgeschlagen ist? Gibt es solche Logs / kann ich das irgendwie nachvollziehen?

 

[BFF]

So mal ganz nebenbei.
Das Teil was Du da per WOL wecken willst ist auch harte Hardware?
Weil weiter oben lese ich irgendwas von Docker oder so.
Mal einen Container oder eine VM wecken ist nicht immer einfach so moeglich.

Finde doch einfach mal die exakte MAC dessen raus was Du wecken willst und versuche das Teil direkt vom Router aus zu wecken. DD-WRT/Open-WRT haben ein taugliches Stueck Software mit an Board.

 

[PatrickS3]

Mal ein anderer Ansatz.
Hast Du auf dem Windows PC, von welchem aus Du mittels wol.exe den Server aufwecken möchtest zufällig Virtualbox installiert?

Ich habe nämlich auch schon das Problem gehabt, dass ich meine beiden NAS nicht wecken konnte - bei installertem Virtualbox.
Virtualbox installiert eine (virtuelle?) Netzwerkschnittstelle. Als ich die im Gerätemanager entfernt habe, funktionierte auch wieder WOL.

 

[BLU1312]

Vielen Dank für eure Antworten.

So mal ganz nebenbei.
Das Teil was Du da per WOL wecken willst ist auch harte Hardware?
Weil weiter oben lese ich irgendwas von Docker oder so.
Mal einen Container oder eine VM wecken ist nicht immer einfach so moeglich.

Finde doch einfach mal die exakte MAC dessen raus was Du wecken willst und versuche das Teil direkt vom Router aus zu wecken. DD-WRT/Open-WRT haben ein taugliches Stueck Software mit an Board.

Ja, das ist ein Dell T30 "TowerServer". Docker und Portainer habe ich über OpenMediaVault (eine auf Debian aufgesetzte Konfigurationsoberfläche) installiert. Der Server selbst läuft aber mit einem normalen Betriebssystem (Debian) und die Netzwerkeinstellungen sind alle unter diesem Debian gemacht.

Das mit dem Router ist eine gute Idee, das werde ich mir anschauen.

Mal ein anderer Ansatz.
Hast Du auf dem Windows PC, von welchem aus Du mittels wol.exe den Server aufwecken möchtest zufällig Virtualbox installiert?

Ich habe nämlich auch schon das Problem gehabt, dass ich meine beiden NAS nicht wecken konnte - bei installertem Virtualbox.
Virtualbox installiert eine (virtuelle?) Netzwerkschnittstelle. Als ich die im Gerätemanager entfernt habe, funktionierte auch wieder WOL.

VirtualBox ist nicht installiert. Weder auf dem Firmen- (da ist es verboten), noch auf dem privaten PC. Auf dem Firmen-PC sehe ich aber einen "Hyper-V Virtual Ethernet Adapter" (der ist auch aktiviert). Ob der auch auf dem privaten PC ist, kann ich gerade nicht sagen, aber ich schaue und werde versuchen den zu deaktivieren und dann nochmal zu testen.

Ergänzung (3. März 2022)

Kurzer Nachtrag: Ich habe auf die Schelle unter OpenWrt (meinem Router) luci-wol-app installiert, "Auf allen Schnittstellen senden" und den Server aus dem "Anzuschaltender Rechner" ausgewählt. Das hat leider nicht funktioniert.

Danach habe ich das etherwake-Paket über Luci installiert und mit etherwake <MAC-Adresse> auf der Shell ausgeführt. Leider auch ohne Erfolg.

Was mir in dem Zuge eingefallen ist: Ich bin bei Vodafone Kabelinternet und nutze deren ConnectBox (wenn das Teil noch so heißt). Da ich einige WLAN habe, z.B. das private, Gast, IOT,... habe ich den Router dahinter laufen. Die ConnectBox läuft auf 192.168.0.1, mein Netzwerk läuft (das kommt von früheren Zeiten, wo ich den Router noch direkt für den Internetzugang hinter einem reinen Modem nutzen konnte) auf 10.50.50.0/24.

Dazu habe ich bei den Interfaces für das LAN-Gateway als IPv4 Gateway die 192.168.0.1 eingetragen. Kann das zum Problem werden, dass das WoL immer zum Gateway gesendet und dort verschluckt wird? Kann es an meiner OpenWrt-Firewall (wisst ihr, ob ich da einfach alles temporär rauslöschen kann, ohne den Router unnutzbar zu machen) liegen? Sorry, dass mir das jetzt erst in den Sinn kam.

 

[fgordon]

Hmm im Bios hat man doch auch oft noch so Krams wie "Wake on PCI(E)" etc auch das muss zusätzlich aktiv sein - nicht nur auf der Karte selber die WOL Funktion.

Also z.B. Wake On PCI-E oder PCI je nach Anbindung der Netzwerkkarte siehe Screenshot.

Sonst reagiert das Board halt meist nicht auf die WOL Signale der Netzwerkkarte.

 

[BLU1312]

Vielen Dank für deine Antwort.

Wie im ersten Beitrag geschrieben habe ich folgende Einträge im BIOS gemacht:

• im BIOS Deep Sleep deaktiviert
• Wake-on-LAN per LAN aktiviert

Das ist auch das, was DELL angibt, was man im BIOS (de-)aktivieren muss.

 

[fgordon]

Ah ok meine (Server-)boards haben halt alle immer noch eine zusätzliche Einstellung auf welche Eingangssignale das Board selber reagiert. Naja dachte schaden kann's nicht xD

Evtl kann man auch ja einen Rechner (z.B. Notebook) direkt per LAN Kabel an die WOL Karte hängen um alles dazwischen auszuschliessen? Ehrlich gesagt keine Ahnung ob das geht - vielleicht weiss das irgendwer.

Falls nicht kann ich das auch mal ausprobieren.... ab Gigabit braucht man ja kein Crosskabel mehr xD

Ansonsten wäre halt noch IPMI (falls das Board das hat) eine Alternative, eine schaltbare Steckdose mit "On after Power Loss" oder ein PiKVM - je nachdem halt wie weit der Server entfernt steht und wie "dringend" das Aufwecken bzw Einschalten gewünscht ist.

Ergänzung (9. März 2022)

Weil mich das einfach interessiert hat - es geht, die direkt zu verbinden und dann aufzuwecken, so dass man damit ausschliessen kann dass irgendwas dazwischen was verschluckt.

Getestet hab ich WOL einschalten mit Linux und etherwake auf dem Notebook (WLAN natürlich aus xD und mit -i Netzwerkkarte direkt angegeben), die Windows-Tools sind ja manchmal etwas zickig weil Windows bei solchen Direkverbindungen ja gerne reinfunkt - "uh das Netzwerk kenn ich nicht da mach ich nix" etc xD

 

[BLU1312]

Vielen Dank für deine Antwort.

Ich hatte es vor ein paar Tagen probiert, dass ich meinem Windows-PC eine feste IP gegeben habe und der Server hat diese sowieso. Danach habe ich den Switch von der LAN-Dose getrennt, so dass der Windows-PC und der Server über den Switch verbunden waren, aber keine Verbindung mehr zum Router bestand. An dem Switch hing noch mein Drucker und das war's.

Danach habe ich nochmal mit WOL.exe und MagicPacket versucht, meinen Server aufzuwecken, aber das hat nicht geklappt. Deinen Vorschlag mit der Direktverbindung Windows-PC <-> Server ohne Switch dazwischen werde ich auch nochmal probieren. Beide haben ja eine GBit-Netzwerkkarte.

 

[fgordon]

Jupp wie gesagt Windows 10 hat bei mir das Paket nicht geschickt, weiss nicht ob es an der Win Software lag die ich genutzt habe (hab schnell irgendwas bei heise gesaugt) oder weil Windows 10 das Netzwerk als "unbekannt" bei der Direktverbindung ausgewiesen hat und deshalb nichts "verdächtiges" rausschickt, hab da auch nicht weiter gesucht.

Mit Linux als WOL Package Sender mit "etherwake" hat es sofort geklappt.

WOL ist manchmal etwas zickig kenn ich auch - aber wenn man es mal am Laufen hat eigentlich erstaunlich zuverlässig.

 

[BLU1312]

Danke für deine Antwort. Dann hatte ich es mißverstanden mit Windows 10.

Ansonsten wäre halt noch IPMI (falls das Board das hat) eine Alternative, eine schaltbare Steckdose mit "On after Power Loss" oder ein PiKVM - je nachdem halt wie weit der Server entfernt steht und wie "dringend" das Aufwecken bzw Einschalten gewünscht ist.

Sehe ich im BIOS, ob das Board IPMI hat? Das "On after Power Loss" ist auch eine Computer-Funktionalität bzw. das PiKVM (auf die Schnelle sieht das für mich aus, als wäre es nur für den Raspberry Pi?!)? Zeitkritisch oder Hochverfügbarkeit ist/braucht bei mir nichts, sonst würde der Server auch immer laufen. Ob das 1, 2 oder 5 Minuten dauert, bis er verfügbar ist, dann ist mir das recht egal, da ich ihn eh im Optimalfall übers Smartphone (OpenHAB) starten würde. Ich will mir einfach nur den Weg zum Server sparen und ihn irgendwann in den Keller stellen können.

Etherwake ist von meinem Raspberry Pi an den Server leider nicht erfolgreich.

Ich habe wieder gefunden, was ich eigentlich auf dem OS eingestellt habe:

https://wiki.ubuntuusers.de/Wake_on_LAN/

Hier habe ich die Methode 1 und 2 umgesetzt. Zum einen das Anlegen eines wol.service mit dem Eintrag

[Unit]
Description=Configure Wake-up on LAN
After=network-online.target

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -s eth12345 wol g

[Install]
WantedBy=basic.target

Danach
sudo systemctl enable wol.service

sudo systemctl daemon-reload

Außerdem die /etc/network/interfaces um

auto eth12345
iface eth12345 inet static
address 10.50.50.10
netmask 255.255.255.0
gateway 10.50.50.1
pre-down /usr/sbin/ethtool -s eth12345 wol g

/etc/default/halt habe ich um

NETDOWN=no

erweitert und die /etc/default/acpi-support neu angelegt mit dem Eintrag

# Add services to this list to stop them before suspend and restart them in
# the resume process.
STOP_SERVICES="networking"

Danach den Server heruntergefahren, allerdings ohne Erfolg.