WakeOnLan - Problem bzw. Ungereimtheit

Server Schulkonsole
1

Hallo zusammen,

nachdem ich die Funktion WakeOnLan einige Zeit nicht mehr benutzt hatte, habe ich vergangene Woche feststellen müssen, dass ich unsere Rechner via Schulkonsole (Device-Manager bzw. Linbo-Synchronisierung) nicht mehr aufwecken kann.

Wann es das letzte Mal funktioniert hat, kann ich leider nicht mehr genau nachvollziehen - denke aber, dass es in den Weihnachtsferien noch geklappt hatte.

Versions-Stand:
Base 7.3.31-0 / Linbo 4.3.31-0 / WebUI 7.3.34 bzw. Update am Freitag auf 7.3.38 / Sophomorix 7.3.13

Hat es bei den neuen Versionen der WebUI (in den Weihnachtsferien <7.3.34? → 7.3.34 →7.3.38) Änderungen gegeben, die das Verhalten erklären könnten?

Eigentlich in Verdacht habe ich die bei uns genutzte, externe Firewall.
Leider hat da die IT-Abteilung der Stadt die Hände drauf, ich habe keinen Zugriff - und bis heute haben wir von dort leider keine Auskunft bekommen, ob von ihrer Seite etwas geändert oder upgedatet wurde - alles sehr träge hier.

Vielleicht kann mir ja jemand meinen Verdacht bestätigen.
Es stellt sich folgendermaßen dar:

Schulkonsole / Linbo-Synchronisierung (Auswahl Rechner - ‘Reboot’ - ‘Wake on lan’):
/usr/sbin/linbo-remote -i 10.0.212.xxx -w 1 -c reboot → weckt nicht auf
/usr/sbin/linbo-remote -g r212-… -w 1 -c reboot → weckt nicht auf

Gleiche Befehle auf der Server-Konsole oder via ssh auf Server wecken ebenfalls nicht auf.
Die dortige Rückmeldung ‘Sending magic packet to 255.255.255.255:9 with 90:2B:34:95:60:6E’
hat mich experimentieren lassen:

/usr/sbin/linbo-remote -i 10.0.212.xxx -u -w 1 -c reboot → weckt auf
Rückmeldung: ‘Sending magic packet to 10.0.255.255:9 with 90:2B:34:95:60:6E’

Der Schalter -u bewirkt den Broadcast ins Subnetz, nicht an die globale 255.255.255.255 .
’wakeonlan 90:2B:34:95:60:6E’ auf der Server-Konsole geht ja auch an die 255.255.255.255 und weckt somit ebenfalls nicht auf.
Andererseits klappt das Aufwecken z.B. von einer VM im 10.0.0.0/16er Netz per Terminalbefehl
’etherwake -i ens18 90:2B:34:95:60:6E’ .
Oder vom Server per ’wakeonlan -i 10.0.255.255 90:2B:34:95:60:6E’ .

Hat mir also wirklich die Stadt ein Ei in die Firewall gelegt und etwas geändert, sodass der globale Broadcast an 255.255.255.255 nicht mehr durchgereicht wird?
Kann das jemand verifizieren?

@ Arnaud
Eine Frage, lieber Arnaud,

wäre es möglich, eine grafische Option für den Schalter -u in die WebUI der Schulkonsole einzubauen?
Dann könnte sich auch ein Anwender behelfen, der mit der Konsole nichts anfangen kann und nur auf der WebUI arbeiten möchte.

Ich bleibe aber weiterhin dran, das Ganze noch mit der Stadt und der Firewall abzuklären.

Vielen Dank und viele Grüße

Andreas

2

Abend,

bin muede, hab das also nicht alles gelesen, vermute aber, dass wir zu dem Thema schon zwei Threads haben, liegt am Ubuntukernel, siehe:

Gruss Harry

3

Hallo Harry,

vielen Dank für die verlinkten Threads.
Schande… Ich hatte gesucht (wakeonlan, wol, …), aber die Beiträge tatsächlich nicht gefunden.
Dabei betreffen sie die gleiche Thematik…

Mal sehen, ob sich Arnaud meldet und er eine Möglichkeit sieht, -u als Option in die WebUI einzubauen - dann wäre ja zu einem großen Teil schonmal geholfen.

Ich lese und recherchiere weiter - wobei es etwas im Nebel stochern ist, da ich an der Schule keinen Zugriff auf die Firewall und die managed-Switches habe.

Muss ich mir vielleicht zuhause noch ein Testsystem hochziehen.
Eventuell habe ich auch noch ein Backup von einem alten Versionsstand.
Denn ich bin eigentlich der Meinung (erinnerungshalber…), dass der Broadcast mit den Standardeinstellungen aus der WebUI schon immer an 255.255.255.255 gerichtet wurde.

Liege ich da falsch?

Gruß Andreas

4

Hallo Andreas,

das Problem kommt vom kernel des lmn Servers. Wenn du den lmn server auf den aktuellen HWE Kernel aktualisierst, dann geht wieder alles so wie vorher: ohne -u oder sowas.

Dominik hat das geschrieben: etwa vor 10 Tagen.

LG
Holger

5

Hallo Holger,

danke für den Hinweis - das kann ich gerne ausprobieren.

Aber warum sollte es am Kernel des Servers liegen?
Sollte ein Fehler im Kernel das Netzwerk-Device falsch beaufschlagen, dann müsste
man ja von einem anderen Rechner bzw. vom Host/Proxmox aus aufwecken können,
wenn der Server heruntergefahren ist.

Aber auch das klappt ja nicht per WOL an den globalen Broadcast.
Nur bei gerichtetem Broadcast ins entsprechende Netzsegment - und dann sind wir
wieder beim Schalter -u bzw. -i 10.0.255.255 von einer beliebigen anderen Station aus.

Gruß Andreas

6

Hallo Andreas,

vielleicht ist dein anderer Rechner auch von dem Kernel-Bug betroffen, der im anderen Thema verlinkt wurde.

VG
Buster

7

Hallo zusammen,

danke für die Tipps.
Der Kernel (verwendete Version 6.8.0-101) war tatsächlich die Wurzel des Übels.

Die für die parallelen Tests verwendete VM war unbewusst ein Kubuntu 24.04 - mit der
gleichen Kernel-Version.
Test von Debian 13 aus lief fehlerfrei.

Somit ist das Thema eigentlich geklärt.
Jetzt interessiert mich nur, welches Kernelmodul des 6.8er für die Fehlfunktion verantwortlich ist.
Mal sehen, ob es sich recherchieren lässt.

Gruß Andreas

8

Hallo Andreas,

Schöne, dass das Problem mit dem Kernel erledigt ist :slight_smile:

Ja, ein Flag `-u` in die Webui ist natürlich machbar, das kommt auf die Todo-Liste.

Gruß

Arnaud

9

Hallo Arnaud,

vielen Dank für die Aufnahme der Anregung auf deine Todo-Liste.
Das wäre ein unkomplizierter Workaround, sollte wieder mal ein derartiges Problem auftauchen.

Die -100er-Serie der 6.8er Kernel scheint die Probleme zu machen.
Einen Hinweis, dass mit dem -103er wieder alles funktioniert habe ich gefunden,
versuche ich noch zu verifizieren.
Daneben sollen auch 6.12er-Kernel betroffen (gewesen) sein, wobei ich das für den
6.12.69 (Debian 13 aktuell) ausschließen kann - von dem aus klappt alles.

Gruß Andreas

10

Ubuntukernel 6.8.0-106-generic aus dem normalen Repo ist da und fixt das Problem, also apt update, apt upgrade, reboot und fertig ist die Laube.

Gruss Harry