Sie sind hier : Homepage →  Die "wake-on-lan" Funktion (2)

Die "wake-on-lan" Funktion mit einem Esprimo 900E-90E

Feb. 2022 - Unsere Linux-Test-Server hier im Haus sind gebrauchte Fujitsu Esprimos vom Typ "E900-E90" sowie "E900-"0-Watt". Das sind schwarze flache Slimline Gehäuse mit einem Fujitsu Mainboard (D3062-A1) für Intel i3, i5 und i7 CPUs aus der 2011 bis 2015 Produktion. Die 4 Speicher-Sockel auf den Mainboards nehmen bis zu 4 Speicher-Streifen mit bis zu 4 GB auf und sind daher noch lange brauchbar. Mit SSDs bestückt sind sie sehr leise und mit 4 Kernen schnell und alles für um die 100 Euro.
.

Der LAN-Chip muß WOL tauglich sein ....

Diese "WOL"-Funktion wurde ab etwa 1995 in die Netzwerk- Chips fast aller Hersteller integriert. Dort wurde ein EEPROM oder Flash Speicher integriert, in das man per Software ein (oder mehrere) Flag(s) setzen kann, sodaß der Chip nicht komplett ausgeschaltet wird.

Natürlich muß auch das Netzteil im eigentlich abgeschalteten Zustand eine verbleibende Versorgungsspannung an das Board liefern, damit der Chip auf Minimal-Empfang bleibt und auf die "Magic Packets" lauschen kann. In den Fujitsu Netzteilen der E900er klickt (beim Ein- und Ausschalten) ein Relais, wenn die Hauptstromversorgung per Front-Taster oder per WOL aus- oder eingeschaltet wird.
.

Im "AMI"-Bios ist WOL vorbereitet

Im BIOS (FUJITSU - American Megatrends Inc. V4.6.4.0) ist unter der Rubrik "Power" die Funktion "Wake-on-Lan" vorhanden, aber teilweise grau hinterlegt, also nicht einsehbar bzw. veränderbar. Unter Linux kann man das mit dem "ethertools" prüfen.
.

BIOS Einstellung - wichtig

Weiterhin muß im BIOS ebenfalls unbedingt unter der Rubrik "Power" der Eintrag "Power-on Source" auf "ACPI controlled" eingestellt werden. Sonst funktioniert das Aufwecken nicht !
.

Seit Feb. 2022 betrachten wir nur noch opensuse Leap 15.3

Laut der diversen Foren-Einträge und Fragen hatte WOL mit opensuse 13.2 bis 15.2 alles mal funktioniert, aber ab Leap 15.3 sei es nicht mehr "gegangen". Ich habe auf unserem (neben mir stehenden) Esprimo E900-E90 Testserver mit mehreren Anleitungen herumspielen können, weil es unkritisch gewesen wäre, wäre er komplett abgestürzt. Ist er aber nicht. Es funktioniert (wieder).
.

Die Vorbereitung - 27.2.2022 - alle 15.3 Updates sind gelaufen

Um auf dem Server X11 und VNC sauber zum Laufen zu bringen (ich brauche das sowieso wegen der XEN VM-Verwaltung), hatte ich die Online-Updates alle durchlaufen lassen, an die 500 MB werden da geladen. Dann erst habe ich angefangen, immer noch als User "root", die Software- Konfiguration für die dauerhafte WOL Funktion nachzurüsten.
.

Ganz wichtig später fürs Aufwecken:
Sinnvolle Vorbereitungen mit den WakeMeOn-Programm ...

Zum Verständnis :
Ich sitze in der Redaktion im 2. Stock und der Server ist im EDV-Rack im EDV-Raum im Erdgeschoß. Also muß das Fern- Ausschalten per "putty" und das Fern- Einschalten per "wake-on-lan" mit einer Windows-Station funktionieren.
.
Und dazu muß das benutzte "WakeMeOnLan"- Programm mindestens einmal aufgerufen, während (oder solange) der (die) Server noch in Betrieb ist (sind), damit in der dortigen Liste aller verfügbaren aktiven Netzwerk-Geräte die MAC-Nummern abgefragt wurden und !!! dort eingetragen bzw. gespeichert werden. Während der "Schlaf-Zeit" verrät der Netzwerk-Chip seine MAC-Nummer nicht.
.

WOL auf Esprimo E900 als Server unter opensuse 15.3

Der Netzwerk-Treiber hat die Gigabit-LED angeschaltet

Die WOL-(Lausch-) Funktion muß per Software in dem Netzwerk-Chip initialisiert werden. Dafür gibt es eine Prüfzeile und eine "init"-Zeile auf der Kommando-Ebene (SSH-Zugang über Putty) des Servers. Das kann auch nur der "root"-User.

Zuerst ist der Name bzw. die Adresse des Chips herauszufinden. Bei unseren Esprimos ist es unter opensuse immer der Port 1 = "eth0". Gebraucht wird dazu das Linux-Programmpaket "ethtool", sollte es noch nicht sowieso schon da sein.
.

  • zypper in ethtool

.
Mit
.

  • [testserver-oben - root] ~ $ ethtool eth0

.
wird abgefagt, ob der Netzwerk-Chip überhaupt WOL tauglich ist. Unsere Chip-Abfrage lieferte die folgende Antwort:
=======================================================
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        MDI-X: on (auto)
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes
=======================================================
.

Die Antwort analysieren :

Diese beiden Zeilen aus der obigen Antwort sind für uns wichtig:
.

  •         Supports Wake-on: pumbg
  •         Wake-on: g

.
Also unser Chip im Esprimo kann WOL. Jetzt muß der Chip "umgeschaltet" bzw. "initialisiert" werden mit

ethtool -s eth0 wol g
.
Jedoch ist diese Initialisierung (zumindest bei opensuse) nicht permanent. Es muß zu einem (nahezu unbekanten) Trick gegriffen werden, um am Ende des Ausschaltvorganges des Servers bzw. beim gezielten Herunterfahren ("shutdown now" oder "poweroff") dem bereits abgeschalteten Netzwerk-Chip nochmals nachhaltig "zu befehlen", doch wieder in einem Minimal-Modus online zu bleiben und auf das (für ihn bestimmte) "Magic Packet" zu lauschen.
.

"WOL init" ausprobieren

Dazu können wir (müssen aber nicht) in einem normalen Linux einen "systemd service" erzeugen - in Form dieser Datei :

/etc/systemd/system/wol.service
.
Ich benutze den "joe"-Editor (nicht den "vi") und schreibe in diese Datei "wol.service" folgende (bereits für Leap 15.3 korrigierte) Zeilen rein :
-----------------------------------------------------------
[Unit]
Description=Wake-on-LAN
After=network-online.target
Wants=network-online.target

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

[Install]
WantedBy=multi-user.target

-----------------------------------------------------------
Und diese Datei wol.service habe ich sicherheitshalber "ausführbar" gesetzt. Ob das wirklich sein müsste ?
.
Mit dieser Zeile wird die Datei wol.service aktiviert und bei jedem "boot" (wichtig : nur beim Boot !!!) ausgeführt.
.

  • systemctl enable wol.service

.
Folgende Quittung sollte jetzt auf dem Monitor erscheinen:

"Created symlink /etc/systemd/system/multi-user.target.wants/wol.service â /etc/systemd/system/wol.service."
.

  • Aber wie oben gesagt, bei opensuse ist das unnötig, weil hier der "shutdown" den Netzwerkchip am Ende abschaltet, warum auch immer. Der Vorschlag kam aus dem Ubuntu Forum.

.

Die "wol.service" Funktion erst noch mal testen :

When you want to run it for a test:
.

  • $ systemctl start wol.service

.
When you want to see what happened:
.

  • $ systemctl status wol.service

.
Das Ergebnis bzw. Anzeige :
.
â wol.service - Wake-on-LAN
Loaded: loaded (/etc/systemd/system/wol.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Sun 2022-02-27 20:42:39 CET; 10s ago
Process: 2295 ExecStart=/usr/sbin/ethtool -s eth0 wol g (code=exited, status=0/SUCCESS)
Main PID: 2295 (code=exited, status=0/SUCCESS)

Feb 27 20:42:39 inhaus-DOM0 systemd[1]: Starting Wake-on-LAN...
Feb 27 20:42:39 inhaus-DOM0 systemd[1]: wol.service: Succeeded.
Feb 27 20:42:39 inhaus-DOM0 systemd[1]: Finished Wake-on-LAN.
$
.

"WOL init" beim Ausschalten erzwingen .....

.

  • Opensuse hat leider (aus meiner Sicht ) eine Macke. Beim Herunterfahren wird der Netzwerkchip abgeschaltet. Das trifft uns hart !!. Daher "überreden" wir opensuse am Schluss des "shutdowns" nochmal, den Netzwerkchip doch wieder mit der stromsparenden WOL Funktion zu reaktivieren.

.
Hierzu erstellen wir in "/etc/sysconfig/network/scripts" ein kleines Skript, das nach der Dekativierung des Chips ganz am Ende des "shutdowns" aufgerufen wird und den Reaktivierungs-Befehl enthält. Als Name verwenden wir "reactivate-wol-eth0".

Das Mini-Skript sieht ganz einfach so aus:
---------------------------------------------

  • #!/bin/bash
  • /usr/sbin/ethtool -s eth0 wol g

---------------------------------------------
.
Ein bash-Script muß natürlich "ausführbar" (executable) gemacht werden. Soetwas mache ich mit dem "mc", so geht es am schnellsten. Dann editieren wir im Verzeichnis "/etc/sysconfig/network/" die Netzwerk-Config Datei "ifcfg-eth0" und fügen nur diese eine Zeile hinzu.

  • POST_DOWN_SCRIPT=reactivate-wol-eth0


Wobei "reactivate-wol-eth0" das zuvor angelegte Skript bezeichnet (das Unterverzeichnis "/scripts" braucht nicht weiter angegeben zu werden).
.

Bei einem virtualisierten Server ist es anders

Bei der DOM0 eines virtualisierten Servers (unter KVM oder XEN) haben wir aber zwei Netzwerk-Einträge, die physikalische Karte "eth0" (ohne IP Adresse) und die virtuelle Bridge "br0" (mit der IP Adresse). Der Eintrag in "eth0" reicht dort nicht aus. Ich schreibe die obige (eine) Reaktivierungs-Zeile daher in beide Konfigs rein.
.

Dieses WOL Gerät muß jetzt am 230V Netz bleiben

Ziehen Sie den Netzstecker raus oder müssen Sie mit dem Server/PC umziehen, muß er ein erstes Mal von Hand eingeschaltet werden. Ist der Strom weg, ist die WOL Funktion auch weg.

.

Dieser Esprimo ist im stromspa- renden 100 mBit/s Modus und lauscht auf sein magisches Paket

Fernabschalten mit "putty"

Wie gesagt, das hier gilt nur erst mal für die Esprimos von Fujitsu. Das Abschalten (bzw. Herunterfahren) geht mit

  1. der Taste vorne auf der Front oder mit
  2. dem ssh Client putty über "poweroff" oder
  3. dem ssh Client putty über "shutdown now".


So weit die Theorie bei einem einfachen Server oder PC.  Ich habe aber mehrere "virtuelle Gäste" am Laufen. Was der "poweroff" Befehl mit den evtl. noch aktiven VM-Gästen anstellt, weiß ich noch nicht.
.

Die "WakemeOnLan" Abfrage
und schon bootet er
und der Lüfter säuselt

Das Starten des wartenden bzw. schlafenden PCs / Servers geht so :

In einem beliebigen WINDOWS Client im lokalen Netz starte ich das "Wache-Auf "-Proramm, welches auf diesem PC schon mal gelaufen sein musste. In ganz kurzer Zeit werden alle irgendwie aktiven IP-V4 units (nochmal) abgefragt und angezeigt.

Ob in der Liste jetzt die MAC Nmmern von Neuzugängen auch erkannt werden, weiß ich nicht, vermutlich eher nein. Denn der Netzwerk-Chip "lauscht" ja nur auf das "Magische Paket" mit seiner MAC Nummer.

Jedenfalls kann ich jeden blliebigen Wunsch-Server (oder PC) mit dem roten Punkt auswählen und mit der F8 Taste aufwecken.

Grüne Punkte bedeuten, der Netzwerk-Chip hat eine IP zugeordnet bekommen und gelbe Punkte sind die in der Liste von früher bekannte Adressen, die aber zur Zeit nicht verfügbar sind.

Es kann durchaus vorkommen, daß unter einer IP Adresse mehrere Listeneinträge mit gelben Punkten - aus alten Zeiten - angezeigt werden.

Für uns sind nur die roten Punkte interessant, denn das sind die uns bekannten "aufweckbaren" Netzwerkgeräte. Auf jeden Fall muß in der jeweiligen Zeile eine MAC Adresse zu sehen sein.
.

Ein Beispiel- Screen-Shot (mit Klick vergrößern)

Zum Vergrößern einfach drauf klicken.
Startseite -- © 2001/2022 - Copyright by Dipl.-Ing. Gert Redlich / Germany - D-65191 Wiesbaden - Telefon-Nummer - Impressum