[erledigt] wakeonlan zeigt keinen Wirkung

[buhtz]

Mit einem anderen Server (ein altes QNAP mit pure Debian drauf) hab ich das schon mal problemlos konfiguriert - also weis ich eigentlich wie es geht.

Mit meinem neuen Server geh es aber nicht. wakeonlan zeigt keine Fehlermeldung. Der Server bleibt regungslos. Die MAC habe ich von der FritzBox, dem BIOS und ip --link ausgelesen. Alle drei Quellen zeigen die selbe MAC. Groß-/Kleinschreibung der Buchstaben zeigen auch keinen Unterschied.

Die Parameter von eno1 sehen auch gut aus.

Code: Alles auswählen

$ sudo ethtool eno1
Settings for eno1:
	Supported ports: [ TP AUI BNC MII FIBRE ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	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: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	Link partner advertised pause frame use: Symmetric
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 100Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000033 (51)
			       drv probe ifdown ifup
	Link detected: yes

Das Board hat nur einen on-board LAN-Port und auch kein WLAN - kann also nix verwechselt haben. Ausser den beiden RAM Riegeln steckt nichts zusätzliches auf dem Board drauf; keiner Erweiterungskarten oder dergleichen.

Es ist ein ASRock J4125-ITX.
Im BIOS gibt es zwei Funktionen die (vermutlich) relevant sind.
PCIE Device Power On (PDF-Seite 36) - Obwohl ich im PCIE keine Karte drin habe.
Boot From Onboard LAN (PDF-Seite 47)

Beide sind aktiviert.

Das Board hängt per LAN an einem kleine Switch; dieser an einem AVM LAN-over-POWER mit passender Gegenstation, die wiederum per LAN-Unterputzkabel mit einer LAN-Dose und diese mit der Fritzbox verbunden ist.
Der aufweckende Client hängt allerdings auch direkt an dem selben switch.

Wenn ich Client-PC (also der Aufwecker) und den Server einschalte, kann ich beide im Router sehen. Sie sind also im selben Netz.

Jetzt steh ich aufm Schlauch. Woran könnte es liegen?

EDIT: Die Hinweise im Wiki kann ich nicht nachvollziehen, da Sie sich mit Kernel und Treibern beschäftigen. Die sind doch aber irrelevant, da dies auf Seiten des Servers auf BIOS-Ebene unabhängig vom Betriebssystem geschieht.

[schwedenmann]

Hallo

Die sind doch aber irrelevant, da dies auf Seiten des Servers auf BIOS-Ebene unabhängig vom Betriebssystem geschieht.

Dummerweise schaltet debian die NIC beim runterfahren komplett ab. Ein wakeronlan hat danach keine Funktion.

Entweder eine systemd-unit schreiben, bei arch ist das ganz gut erklärt,wenn du dort wakeonlan googlst. Ansonsten muß du,wenn du keinen networkmanager hast, oder bei der /etc/network/interfaces einige Einträge (ev. sogar ein separates script) machen,um die NIC nicht komplett abzuschalten beim shutdown.

mfg
schwedenmann

[buhtz]

Dummerweise schaltet debian die NIC beim runterfahren komplett ab. Ein wakeronlan hat danach keine Funktion.

Was ist "NIC"?

Laut ethtools sehe ich doch das g. Geht doch. Auch das ist im Debian-Wiki (s.o.) und im Arch-Wiki gleich zu Beginn eindeutig beschrieben.

Bei meinem alten Debian Server (Debian 9) hatte ich nicht so ein Problem. Da hat Debian scheinbar nix abgeschaltet.
Und der Aufwecker Client-PC (ebenfalls Debian 10) kann übrigens auch aufgeweckt werden. Da schaltet Debian auch nichts aus.

Und was genau bedeutet "abschalten"? Wie kann den Debian auf dem LAN-Chip oder im BIOS rumpfuschen? Und warum sollte es das überhaupt tun?

[rhHeini]

Schau mal auf die LEDs am Netzwerkport (NIC). Wenn die aus sind wenn das Board schläft kannst Du machen was Du willst, das wakeonlan wird nicht funzen. Du musst das ethtool beim Shutdown ausführen und den NIC in Bereitschaft schalten = da leuchtet noch ne LED.

Das Boot From Onboard LAN kannste abschalten, Du willst nicht von einem Image das übers LAN bereitgestellt wird booten.

Rolf

[schwedenmann]

Hallo

Und was genau bedeutet "abschalten"? Wie kann den Debian auf dem LAN-Chip oder im BIOS rumpfuschen? Und warum sollte es das überhaupt tun?

weil ei debian,wie auch ein Arch die NIc (Netzwerkarte) beim shutdown ausschalten,dann nützt auch kein wakeonlan im Buios oder -g bei der NIC. Bei Freebsd und win geht wakeonlan outofthebox,bei debian ist da frickeln angesagt.

mfg
schwedenmann

[buhtz]

weil ei debian,wie auch ein Arch die NIc (Netzwerkarte) beim shutdown ausschalten

Dazu wird im Debian-Wiki und im Arch-Wiki nichts erwähnt, dass dies standardmäßig oder überhaupt passieren würde.
Ist das Verhalten irgendwo dokumentiert?

bei debian ist da frickeln angesagt.

Wie ich sagte, auf meinem alten (nicht mehr greifbaren) Debian 9 Server ging das ohne Frickeln - out of the box.

Schau mal auf die LEDs am Netzwerkport (NIC). Wenn die aus sind wenn das Board schläft kannst Du machen was Du willst, das wakeonlan wird nicht funzen. Du musst das ethtool beim Shutdown ausführen und den NIC in Bereitschaft schalten = da leuchtet noch ne LED.

Die LED ist aus.
Warum zeigt mir ethtools dann aber immer ein g? Ergibt für mich keinen Sinn.

Und welchen Befehl soll ich ausführen? ethtool -s interface wol g ist IMHO sinnfrei, da der g ja schon gesetzt ist.


Ich verstehe sicher etwas falsch. Aber aktuell habe ich das Gefühl, wir reden aneinander vorbei.
Ich führe den Abschnitt "Checking WOL" laut Debian-/Archi-Wiki aus und komme zu dem Ergebnis, dass WOL bei mir aktiviert ist. D.h. IMHO es ist kein weiterer Schritt nötig. Alle weiteren Schritte in den Wikis beziehen sich auf die Situation, wenn WOL nicht aktiviert ist - was bei mir nicht der Fall ist.

[rhHeini]

Weil wenn Du im Betrieb das ethtool nutzt den laufenden Zustand anzeigst. Das der NIC in der Ruhe tot ist zeigt Dir das keine LED mehr leuchtet. Nur wenn der NIC angewiesen wurde Bereitschaft zu zeigen was eine leuchtende oder blinkende LED anzeigt wird der Rechner auf das wakeonlan reagieren.

Da Debian (und andere Linuxe) aber seitdem ich mit Sarge angefangen habe einen Fileserver zu betreiben immer beim Shutdown den NIC totlegt musst Du an der passenden Stelle (nimm halt das Arch-Wiki als Anhaltspunkt) ein ethtool -s interface wol g ausführen, und zwar nachdem das Netzwerk abgeschaltet wurde.

Und das Dein alter Server zufälligerweise ging .... vergiss es, Du sieht ja jetzt das das neue Board so nicht geht.

Rolf

[schwedenmann]

Hallo

Ich führe den Abschnitt "Checking WOL" laut Debian-/Archi-Wiki aus und komme zu dem Ergebnis, dass WOL bei mir aktiviert ist. D.h. IMHO es ist kein weiterer Schritt nötig.

Doch,wenn du ein shutdown -h now ausführst,wird das Netzwerk, incl. der NIC ausgeschaltet,dann kann auch ein magic-packet die "tote" NIC eben nicht mehr aufwecken.
Du mußt zusätzlich an der interfaces rumschrauben, oder dir wie im archwiki beschrieben,eine systemd-unit schreiben,damit die NIC und das Netzwerk beim shutdown,eben nicht komplett runtergefahren wird.

mfg
schwedenmann

P.S.
hier den Abschnitt den ich im Arch-Wiki meinete

/etc/systemd/system/wol@.service

[Unit]
Description=Wake-on-LAN for %i
Requires=network.target
After=network.target

[Service]
ExecStart=/usr/bin/ethtool -s %i wol g
Type=oneshot

[Install]
WantedBy=multi-user.target

[MSfree]

Da Debian (und andere Linuxe) aber seitdem ich mit Sarge angefangen habe einen Fileserver zu betreiben immer beim Shutdown den NIC totlegt

Das Problem, daß NICs mit dem shutdown "ausgeschaltet" werden, ist aber bisher nicht generell vorhanden gewesen. Meine Stretch-Kiste läßt sich z.B. problemlos mit WoL wecken, einfach indem ich im BIOS WoL anschalte. Gleiches galt für meinen alten Q9300 unter Lenny, den ich gelegendlich mit WoL gestartet habe. Erst seit ich da Bullseye drauf habe, ist der nicht mehr aufzuwecken.

Mit welcher Debian- bzw. Kernelversion das los ging, kann ich dir nicht genau sagen, bis Stretch schien es jedenfalls mit meinem Hardwarepark zu gehen. Ich denke, daß es mit dem Kernelmodul für das Netzwerkmodul und der Kernelversion zu tun hat.

[buhtz]

Bleibt die Frage, warum Debian das überhaupt tut? Ich gehe davon aus, dass sich Debianer etwas dabei denken.

Die vorgeschlagene Lösung kann ich noch nicht ausprobieren, da die Maschine gerade einen mehrtätigen Job erledigt.

Aber die Lösung ist auch nur eine Krücke.
https://de.wikipedia.org/wiki/Leave-Me-Alone-Box

Ich schalte etwas ein, was das OS vorher ausgeschaltet hat. Es erscheint mir sinnvoller, dem OS beizubringen, dass Ausschalten einfach mal sein zulassen. Ist das nicht machbar?

[MSfree]

Bleibt die Frage, warum Debian das überhaupt tut?

"Debian" tut gar nichts. Die Debianentwickler holen sich lediglich den Sourcecode für alles, was zum Debiansystem gehört, von diversen GIT-Servern und compilieren daraus das Debian Betriebssystem.

Wenn irgendwer etwas getan hat, dann Redhat als Hauptentwickler von Systemd und die diversen Firmen, die zum Linuxkernel beitragen. Wenn da jemand etwas einbaut, ist es halt auch in Debian drin.

[fischig]

Ohne systemd und mit openrc funktioniert wakeonlan hier sowohl in devuan-beowulf (buster) als auch in Debian bullseye nach shutdown -h now.

[buhtz]

"Debian" tut gar nichts. Die Debianentwickler holen sich lediglich den Sourcecode für alles

Naja, ganz so einfach ist es zum Glück nicht. Debian ist ja nicht ohne Grund Debian. Es macht in einigen Bereichen einfach sein eigenes (strikteres) Ding - durch Anpassungen. Und das ist gut so!

Welche Komponente ist den für das Abschalten von WOL beim Herunterfahren verantwortlich? An wen kann man sich wenden, um die Hinter- und Beweggründe zu erfahren?

btw: Wer auch immer das hier besser durchsteigt und Wiki-Schreibrechte hat. Bitte den Artikel mal anpassen und präzisieren. Der Abschnitt "Check WoL" ist eigentlich ziemlich klar und leitet vermutlich jeden Neuling fehl. Wenn das "g" da ist, müsste es ja gehen.

[schwedenmann]

Hallo

bei mir auf einem Server (also nox) steht in der /etc/networkinterfaces (inet wird nur per interfaces realisiert):

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp2s0
iface enp2s0 inet dhcp
# This is an autoconfigured IPv6 interface
iface enp2s0 inet6 auto
post-up /sbin/ethtool -s $IFACE wol g
post-down /sbin/ethtool -s $IFACE wol g

Damit funktioniert für den PC wakeonlan mit Debian-Sid

mfg
schwedenmann

P.S.
Für Arch habe ich die thread verlinkte systemd-unit aus dem archwiki verwendet und es funktioniert wakeonlan damit auch bei archlinux.

[buhtz]

Die LED am LAN-Port ist kein verlässlicher Indikator. Die ist bei mir immer aus, wenn das Gerät nicht "eingeschaltet" ist.

Das tatsächlich wirkt ethtool -s eno1 wol g wie beschrieben. Und in /etc/network/interfaces lässt es sich persistent setzen.

Wie gesagt: Beide Wiki-Einträge diesbezüglich sind nicht nur unvollständig, sondern irreführend. Ohne Hintergrundwissen kommt man nicht drauf, was da wirklich gemeint ist. Das sollte umgeschrieben werden.

Danke für eure Hilfe.

[weshalb]

Das sollte umgeschrieben werden.

Mach doch.

[buhtz]

Mach doch.

Ich leiste gerne meine FOSS-Beitrag zu Dingen, von denen ich etwas verstehe.

Ich denke es ist nach diesem Thread klar, dass ich nicht verstehe warum es so ist wie es ist. Dem Wiki-Beitrag (genau wie mir) fehlen die Hintergrundinfos.

Scheinbar ist ja auch weiterhin klar, welche Komponente für das Abschalten zu ständig ist und warum dies geschieht.

[weshalb]

Mach doch.

Ich leiste gerne meine FOSS-Beitrag zu Dingen, von denen ich etwas verstehe.

Ich denke es ist nach diesem Thread klar, dass ich nicht verstehe warum es so ist wie es ist. Dem Wiki-Beitrag (genau wie mir) fehlen die Hintergrundinfos.

Scheinbar ist ja auch weiterhin klar, welche Komponente für das Abschalten zu ständig ist und warum dies geschieht.

Es reicht schon, deine Erkenntnisse für ein Troubleshooting ohne Gewähr einzufügen. Ob du davon nun was verstehst oder nicht, ist dabei zweitrangig.