FB 7590 - WOL über Web geht nicht

Centauri39

Mitglied
Mitglied seit
4 Jun 2006
Beiträge
371
Punkte für Reaktionen
1
Punkte
18
Mein PC ist eigentlich per WLAN an der FB, aber um WakeOnLAN nutzen zu können, ist zusätzlich ein LAN-Kabel dran.
WOL ist im BIOS aktiviert.
Heimnetz-intern geht es, aber nicht übers Internet.
Dass es übers Internet nur mit einem MyFritz-Konto geht, wo ich erst mittels Browser auf die FB-Oberfläche gehen muss, ist mir bekannt.
Ich habe ein MyFritz-Konto, über das ich die FB erreiche. Somit kann ich auf Netzwerkeinstellungen zugreifen und insofern auch auf die Netzwerk-Option "Diesen Rechner starten" (bei dem betreffenden Netzwerkgerät).
Aber es passiert nichts.

Wo könnte bitte der Fehler sein?
 
Lässt du den PC nur aufs Magic Packet lauschen? Dabei gibt es zuweilen Unterschiede. Ich kenne einige WOL Tools, da wacht ein PC nicht auf, wenn er nur aufs Magic Packet lauscht.
 
Es geht nur um den Zugriff aus dem Internet, nicht um den lokalen.
Eigentlich nutze ich dazu gar kein Tool, weil das eh nicht geht. Stattdessen nehme ich nur den Browser, da ich über das MyFritz-Konto in die FB-Oberfläche rein gehe.
Port 9 ist weitergeleitet auf einen 5-stelligen externen Port.
Dort ist dann im Netzwerk beim gewünschten PC die Option "Computer starten", aber da passiert nichts.
 
Port 9 ist weitergeleitet auf einen 5-stelligen externen Port.
Du meinst der 5-stellige Port, mit dem Du aus dem Internet die FritzBox erreichst, ist auf den lauschenden Port 9 des PV weiter geleitet?
 
Nein, das ist ein anderer, 5-stelliger Port.
 
Bitte skizziere die Verbindungen des PCs via WLAN und LAN incl verwendeten IPs intern und evtl den MACs (diese kannst Du ruhig auf die letzten zwei Oktetts verschleiern)

Alternativ dazu könnten passende Passagen aus den Supportdaten oder Screenshots der beiden Verbindungen der Eigenschaften der "einzelnen" Geräte aus dem F!B GUI.

Ebenso wären wohl die Freigaben bzw Weiterleitungen in irgendeiner belastbaren Form von Vorteil.

Die bereits vorhanden Threads zum Thema WOL und der FritzBox (vorallem bei Zugriff von Extern) hast du Bereits (zumindest) in diesem Forum bereits konsultiert?
 
Diese Weiterleitung ist schon so lange in der FB drin, dass ich gar nicht mehr weiß, warum ich die damals eingerichtet hatte. Ich vermute, dass ich das damals aus der Überlegung heraus tat, dass es wohl die Sicherheit erhöhen würde, wenn ich für den externen keinen Standard-Port nutze.

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Der lokale Zugriff innerhalb meines WLAN/LAN's geht jetzt auch nicht mehr.
Der Ziel-PC hat die lokale IP 192.168.178.20 (im LAN) der Client-Laptop hat die 192.168.178.32 (im WLAN).

Die Weiterleitung ist für das LAN des Ziel-PC eingerichtet, und hat lokal die 9, aber extern eine 10xxx.
Weder TCP noch UDP erfolgreich.
Es existieren weitere Weiterleitungen, aber die betreffen nur VNC und SSH, jedoch nicht WOL.

Negative Zugriffsversuche:
1. Vom Android (leider noch sehr alte Version) mit WakeOnLAN-App, wo ich die lokale Ziel-IP, den Wol-Port (mit 9 oder 10xxx versucht) und die Broadcast-IP mit den 4 mal 255 einstellen kann.
Hat heute einmal geklappt, danach nie mehr wieder. Funktioniert immer nur zufällig.

2. Vom Android-App MyFritz (leider auch sehr alt) zur FB, sowohl mit lokalen Daten als auch mit MyFritz-Adresse. Keine Reaktion.

3. Vom besagten Handy mit Opera-Mini, auch keine Verbindung zum FB-GUI.

4. Vom MX-Linux-19.4-xfce-Laptop (im WLAN) mit Firefox 92 über MyFritz-Konto das FB-GUI sowie die dortigen Netzwerkgeräte erreicht, aber keine Reaktion auf die Option "Rechner starten" .

5. Vom Win10 Home Surface Book 3 mit SimpleWakeOnLAN-App ebenfalls keine Reaktion des Ziel-PC's auf WOL-Signal.

Das Handy scheint zu alt zu sein, ich muss wohl doch mal ein neues in Betracht ziehen.
Aber die Versuche vom Laptop oder Surface hätten erfolgreich sein müssen, zumindest die lokalen oder die mit Firefox und MyFritz-Konto.

Allerdings erfolgten die Versuche vom Laptop und Surface aus meinem eigenen WLAN heraus, wobei ich im DNS-Rebind-Schutz die MyFritz-Adresse aber schon drin habe.
 
Zuletzt bearbeitet von einem Moderator:
Der lokale Zugriff innerhalb meines WLAN/LAN's geht jetzt auch nicht mehr.
Der Ziel-PC hat die lokale IP 192.168.178.20 (im LAN) der Client-Laptop hat die 192.168.178.32 (im WLAN).

4. Vom MX-Linux-19.4-xfce-Laptop (im WLAN) mit Firefox 92 über MyFritz-Konto das FB-GUI sowie die dortigen Netzwerkgeräte erreicht, aber keine Reaktion auf die Option "Rechner starten" .
Teste mal was passiert wenn Du Im (W)LAN, von deinem Linux-Laptop mit etherwake ein magic-Paket an die MAC-Adresse des Ziel-PCs (192.168.178.20) sendest.
Die MAC-Adresse vom Ziel-PC findest Du in der FritzBox und/oder mit einem arping (als dem package iputils-arping) auf die IP-Adresse 192.168.178.20 bei eingeschaltetem Ziel-PC oder evtl. auch schon im arp-cache von Linux-Laptop (mit "arp -av"):
Code:
sudo arping -c 3 -I wlan0 192.168.178.20
(wlan0 evtl. anpassen).
Auf dem Linux-Laptop kannst Du das senden des magic-Paket auch mit tcpdump anzeigen lassen:
Code:
sudo tcpdump -vvveni wlan0 ether proto 0x0842
und danach auf dem Linux-Laptop:
Code:
sudo etherwake -i wlan0 -D <MAC-Adresse-Ziel-PC>
(wlan0 evtl. anpassen und MAC-Adresse-Ziel-PC anpassen und ohne spitze Klammern).

EDIT:

Wenn das mit etherwake nicht funktioniert, dann auch mit wakeonlan vom Linux-Laptop (im W/LAN) versuchen:
Code:
sudo tcpdump -vvveni wlan0 udp port 9
Code:
sudo wakeonlan -i 192.168.178.20 <MAC-Adresse-Ziel-PC>
 
Zuletzt bearbeitet:
Die Ping-Befehle sind ok, sofern der Ziel-PC läuft (ist auch klar, runtergefahren "existiert" der Ziel-PC ja nicht für Pings).
Aber alles, was sich auf WOL bezieht, scheitert (Das Senden scheint ok zu sein, aber es kommt nichts an, also keine Reaktion).

Ich denke, ich sollte noch mal etwas genauer auf die beteiligten Geräte eingehen:

Der Ziel-PC ist, wie gesagt, ein MX 19.4 xfce. Dieser ist per WLAN an der FB.
Das LAN ist zwar angeschlossen, wird aber normal nicht im MX genutzt.
Das LAN ist ausschließlich für WOL da (oder mal ausnahmsweise für Notfälle, falls das WLAN streikt).
Die LAN-MAC sowie die LAN-IP unterscheiden sich jeweils von der WLAN-MAC und WLAN-IP, da dazu unterschiedliche Adapter genutzt werden.
Relevant dürfte hier nur die LAN-MAC und LAN-IP sein, da ja WLAN erst bei gebootetem MX verfügbar ist.

Der Client-Laptop ist auch ein MX in der gleichen Version und wird nur im WLAN benutzt.

In der FB sind beide Rechner eingerichtet, und laufen beide problemlos mit VNC und/oder SSH.
Beide User der beiden Single-User-Rechner sind eingerichtet.
Passworte stimmen auch.

Ich weiß nicht, wo ich noch suchen könnte.
 
Ohne spezielle Hardware-Vorkehrungen (auf dem Mainboard) oder BIOS-Einstellungen funktioniert WoL nur dann, wenn das OS das System (genauer: den/die Interrupt-Controller) zuvor passend konfiguriert hat (über das ACPI) - und das machen die meisten nur dann, wenn das System NICHT heruntergefahren wurde, sondern sich zumindest noch in einem Sleep-Zustand befindet.

Das kann von S1 bis S5 gehen, muß aber bei S5 nicht mehr funktionieren, denn G1 (der "Bereitschaftszustand" im ACPI) umfaßt nur S1 bis S4, während S5 zu G2 gehört. Die meisten PCs OHNE spezielle WoL-Settings im BIOS bieten ein Aufwachen per Wake-on-LAN nur dann an, wenn das ACPI vom (herunterfahrenden) OS entsprechend "angewiesen" wurde, das System zu wecken bzw. dieses Aufwachen zuzulassen.

Ich vermute mal, daß die vorhergehenden Versuche, wo das funktionierte, auf ein System trafen, was eben zuvor nicht explizit heruntergefahren wurde. Das verwendete MX-Linux ist (in meinen Augen) auch ausreichend exotisch, damit es hier nicht allzu viele gibt, die dieses OS selbst verwenden, daher wird es auch kaum Erfahrungen dazu geben, wie sich das System beim "Herunterfahren" (manuell oder automatisch als Energiespar-Mechanismus) GENAU verhält und wie es die ACPI-Funktionen verwendet.

Zur Diagnose empfehle ich hier den Inhalt von /proc/acpi/wakeup (dieses Pseudo-File sollte auch unter MX-Linux vorhanden sein) und die Verwendung von ethtool - mit letzterem läßt sich ggf. (abhängig von den ganzen anderen Randbedingungen) auch einstellen, daß/ob/wie der LAN-Adapter überhaupt auf WoL-Versuche reagieren soll. Zumindest die "Anzeige" für das betreffende Netzwerk-Interface sollte schon Aufschluß geben, ob da das Aufwachen per Magic-Packet (etwas anderes macht das FRITZ!OS nicht) richtig konfiguriert ist. Bei einem Wake-on: d in der Anzeige wird das dann auch nichts werden - zu den Fähigkeiten und zur Verwendung von ethtool empfehle ich die Man-Page.

EDIT: S0 in S1 geändert - S0 ist "arbeitsbereit" und adäquat zu G0 und nicht in G1 "enthalten".
 
Ich fahre MX (basiert nebenbei bemerkt auf Debian) immer ganz normal runter.
Vorher hatte ich längere Zeit Linux Mint (mehrere Versionen bis zuletzt 19.3 MATE), da gibt es zwar den proc-Ordner, aber nicht diese wakeup-Datei.
Trotzdem lief WOL eigentlich recht gut. (EDIT: WOL lief dort nur dann nicht mehr, wenn ich hinten den Hauptschalter aus hatte)
Das Einzige, was ich außer dem WOL im BIOS (das Motherboard ist übrigens ein Z170A Gaming M5) zusätzlich aktiviert habe, ist dass ich den PC mit Druck auf eine beliebige Taste des USB-Keyboards booten kann.

Der Inhalt meiner wakeup-Datei in MX sieht so aus:
Code:
Device    S-state      Status   Sysfs node
PEG0      S4    *enabled   pci:0000:00:01.0
PEGP      S4    *disabled  pci:0000:01:00.0
PEG1      S4    *disabled
PEGP      S4    *disabled
PEG2      S4    *disabled
PEGP      S4    *disabled
RP09      S4    *disabled
PXSX      S4    *disabled
RP10      S4    *disabled
PXSX      S4    *disabled
RP11      S4    *disabled
PXSX      S4    *disabled
RP12      S4    *disabled
PXSX      S4    *disabled
RP13      S4    *disabled
PXSX      S4    *disabled
RP01      S4    *enabled   pci:0000:00:1c.0
PXSX      S4    *enabled   pci:0000:02:00.0
RP02      S4    *disabled
PXSX      S4    *disabled
RP03      S4    *disabled
PXSX      S4    *disabled
RP04      S4    *disabled
PXSX      S4    *disabled
RP05      S4    *disabled
PXSX      S4    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled
PXSX      S4    *disabled
RP08      S4    *enabled   pci:0000:00:1c.7
PXSX      S4    *disabled  pci:0000:03:00.0
RP17      S4    *disabled
PXSX      S4    *disabled
RP18      S4    *disabled
PXSX      S4    *disabled
RP19      S4    *disabled
PXSX      S4    *disabled
RP20      S4    *disabled
PXSX      S4    *disabled
RP21      S4    *disabled
PXSX      S4    *disabled
RP22      S4    *disabled
PXSX      S4    *disabled
RP23      S4    *disabled
PXSX      S4    *disabled
RP24      S4    *disabled
PXSX      S4    *disabled
RP14      S4    *disabled
PXSX      S4    *disabled
RP15      S4    *disabled
PXSX      S4    *disabled
RP16      S4    *disabled
PXSX      S4    *disabled
GLAN      S4    *disabled
XHC      S4    *enabled   pci:0000:00:14.0
XDCI      S4    *disabled
HDAS      S4    *disabled  pci:0000:00:1f.3

EDIT:
Ich kann den ersten kleinen Erfolg vermelden:
Soeben ist es mir gelungen, den PC vom Laptop aus über das FB-GUI zu starten.
Auf DIE (folgende und zufällig im Web gefundene) Lösung wäre ich im Leben niemals selbst gekommen:

In MX gibt es in
Code:
/etc/default/tlp
den Eintrag
Code:
# Disable wake on LAN: Y/N.
WOL_DISABLE=Y

Den muss man von Y auf N ändern und normal rebooten, was ich vorsichtshalber auf beiden Rechner gemacht habe. Nach dem darauf folgenden nächsten Runterfahren, geht WOL, zumindest auf die genannte Weise (mit einer kleinen Verzögerung).
Ob weitere Methoden für WOL auch gehen, weiß ich aktuell noch nicht.
Wenn ich weitere Testergebnisse habe, melde ich mich wieder.
 
Zuletzt bearbeitet:
Sollte das Device GLAN am Ende irgendein GbE-Adapter sein (einen anderen Namen, der an ein Netzwerk-Gerät erinnern würde, sehe ich nicht in der Liste - die Namen werden vom Hersteller in der DSDT festgelegt, wobei GLAN ein gebräuchlicher für einen ebensolchen Adapter wäre)), dann darf der (nach der oben gezeigten Ausgabe) den PC aber nicht aus S4 holen. Ja, es gibt eigentlich bei Dir gar kein Gerät, was ein Aufwecken aus S5 bewerkstelligen könnte - das läßt mich daran zweifeln, daß Dein Mainboard das auch wirklich beherrscht. Auf einem (älteren) MacMini sieht der Eintrag für den GbE-Adapter (unter openSUSE Tumbleweed) hingehen so aus:
Rich (BBCode):
vidar:~ $ grep "^G" /proc/acpi/wakeup
GIGE         S5    *enabled   pci:0000:00:0a.0
und der kann dann - aber auch nur mit den passenden Einstellungen für den Netzwerk-Adapter per ethtool - auch tatsächlich per WoL gestartet werden, solange er nur Strom hat - auch nach einem kompletten Power-Loss. Anhand Deiner Ausgabe oben würde ich nicht annehmen, daß dieses Gerät ÜBERHAUPT automatisch von S5 nach G0 wechseln kann - selbst anhand der RTC vermutlich nicht. Wobei fehlerhafte ACPI-Tabellen auch noch eine Erklärung sein könnten, dazu später.

Das "Testen" der verschiedenen Möglichkeiten mußt Du nun mal selbst übernehmen ... damit das WoL am Ende tatsächlich funktioniert, müssen die Einstellungen im BIOS und im OS dazu passen und das System (als Gesamtheit aus OS und BIOS) beim Herunterfahren auch die richtigen Einstellungen aktivieren. Egal, was das für ein Mainboard ist - das Handbuch dazu mußt Du Dir auch selbst suchen und ermitteln, ob die BIOS-Einstellung zum WoL TATSÄCHLICH auch das Aufwachen aus S5 betrifft.

Wenn das so wäre, sollte der PC ja IMMER per Magic-Packet geweckt werden können, solange er nur Strom hat - das sind aber in aller Regel "Fernwartungsfunktionen" (bis hin zum Einsatz der Intel Management Engine - IME), die auch Business-Computern vorbehalten sind (wo dann in der Nacht zentral irgendwelche Updates ausgespielt werden können) und die müssen auf Gaming-Mainboards nicht ebenso vorhanden sein. Das UEFI-BIOS der Apple-Geräte unterstützt das aber (s.o.) in aller Regel auch - wobei auch hier das verwendete OS noch jede Menge Mitspracherecht hat über das ACPI.

Wenn das OS die Einstellungen seinerseits passend setzt beim Herunterfahren (zumindest die, die es aus seiner eigenen Sicht sein sollten), dann muß das BIOS, um da noch diese Einstellungen "überstimmen" zu können, die entweder direkt beim ACPI-Aufruf ignorieren/ändern oder den "Abschaltbefehl" (der das System dann nach G2 schickt) noch einmal zum Anlaß nehmen, seinerseits die notwendigen Einstellungen (erneut) vorzunehmen.

Bei älteren BIOS-Versionen gab es noch einem Punkt "ACPI-aware OS" (oder ähnliches) - damit wurde dann die Programmierung der Sleep-Zustände komplett an das OS übertragen, egal was ansonsten noch im BIOS einzustellen war. Da interessierte die BIOS-Einstellung für WoL (sofern überhaupt vorhanden) dann auch nicht länger ... was das OS in Auftrag gab, wurde 1:1 so umgesetzt. Heute gibt es mit den ganzen UEFI-Implementierungen so viele unterschiedliche Möglichkeiten, daß man eben selbst probieren muß, was bei der eigenen Technik wirkt.

Der einfachste Test ist es schon mal, das aufzuweckende Gerät nicht wirklich "herunterzufahren", sondern nur in einem Stromspar-Zustand zu schicken, der max. bis S4 geht. Wenn das Gerät dann per Magic-Packet aufwachen kann, liegt es wohl doch daran, daß ein Aufwachen aus G2 gar nicht machbar ist. Wenn es dann (mit derselben Technik) vorher wirklich funktioniert haben sollte, dann hat da wohl das zuvor verwendete OS (so richtig schlau werde ich nicht aus dem oben Geschriebenen, WAS sich da nun geändert hat, daß es "plötzlich" nicht mehr funktioniert) von sich aus das Gerät nur in S4 geschickt beim "Herunterfahren" - das meinte ich oben, als ich schrieb, daß mit der Distro vermutlich ausreichend mangelnde Erfahrungen hier vorliegen (egal, auf welchem Zweig die basiert - die "Feinheiten" machen hier den Unterschied), um das wirklich sagen zu können.

Zumindest "im laufenden Betrieb" ist ja das Wecken durch GLAN offensichtlich schon mal deaktiviert, wie man an Deiner Ausgabe sieht (das zu ethtool Geschriebene solltest Du vielleicht auch noch einmal lesen und "abarbeiten") - wenn das nicht beim Übergang in einen der Stromspar-Zustände noch geändert wird, wird das Erwecken GAR NICHT funktionieren (zumindest nicht, solange nicht das BIOS mitarbeitet und das selbst übernimmt).

Den wakeup-Status eines Gerätes kann man nebenbei bemerkt mit einem echo [I]device [/I]> /proc/acpi/wakeup hin und her schalten - auch das wäre zumindest mal einen Versuch wert. Üblicherweise übernimmt heutzutage der udevd (oder etwas ähnliches, ggf, auch der systemd) beim Herunterfahren des Systems (oder auch beim Übergang nach G1) das Setzen der passenden Einstellungen - und wenn er (bzw. "das OS") das richtig macht, sollte man ihm nicht noch an anderen Stellen in die Parade fahren.

Man kann ja auch einfach mal per Skript dafür sorgen, daß beim Herunterfahren von MX-Linux (wenn die anderen Tests ergeben, daß das erfolgsversprechend sein könnte) der Wakeup-Status für GLAN tatsächlich auch auf enabled steht und ihn ansonsten noch ändern - vielleicht reicht das schon als "Nachhilfe". Ansonsten kann man ja auch selbst dafür sorgen, daß ein "Herunterfahren" eben in S4 endet und nicht in S5 - ein Unterschied hinsichtlich Stromverbrauch ist praktisch nicht existent.

Aber die verschiedenen Stellen, wo man da etwas einstellen kann, können sich ergänzen oder auch widersprechen (bzw. die Einstellungen wieder "überschreiben") - nicht ganz umsonst ist die vernünftige Konfiguration der Stromspar-Zustände über das ACPI immer noch eine der Schwachstellen von Linux - wobei da zu einem Gutteil die Hersteller schuld sind, weil die gerne mal mit unvollständigen/falschen ACPI-Tabellen auflaufen, solange nur ihre eigenen Tests mit Windows das richtige Ergebnis zeigten - das meinte ich weiter oben mit der Möglichkeit, daß die Anzeigen, die max. bis S4 gehen für alle Devices, auch durchaus fehlerhaft sein könnten.

Du wirst jedenfalls - wenn Du die "Diagnose" auf das Drücken des Buttons im FRITZ!OS-GUI und die Tatsache, daß der PC dann nicht angeht, reduzierst - auch durch ständiges "Probieren" nicht weiterkommen ... zumindest nicht durch wahlloses (denn systematisches Testen ist letztlich auch "Probieren"). Zunächst einmal solltest Du Dich auf eine Stelle festlegen, wo man das (sauber) konfiguriert - wie erwähnt, können dieselben Einstellungen an mehreren Stellen auch kontraproduktiv sein.

Wenn das BIOS tatsächlich das Aufwachen aus S5 unterstützen sollte (das findet man im Handbuch oder im Internet, denn das Mainboard ist vermutlich kein Einzelexemplar und es wird andere (Besitzer) mit ähnlichen Fragen geben), dann wäre das u.U. vorzuziehen, weil es (a) OS-unabhängig ist und (b) das System auch aus einem "tieferen" Schlafzustand holen kann. Wenn nicht, solltest Du das Ganze ausschließlich vom OS machen lassen.

Das heißt dann u.U. auch, die Einstellungen im BIOS ggf. wieder zu deaktivieren - wobei hier wirklich nur "Probieren" hilft, denn manchmal ist das auch (je nach BIOS) nur die "generelle Erlaubnis" und gar nicht das Programmieren der Interrupt-Controller. Hier kann man üblicherweise auch einfach testen, wie ein Herunterfahren das System hinterlassen hat - ist das System in S4 und kann geweckt werden, aber nach einem Aus- und Wiedereinschalten der Stromversorgung des PCs funktioniert auch das nicht mehr, dann hat eben das zuletzt verwendete System per ACPI alles korrekt eingestellt, aber das Unterbrechen der Stromversorgung diese "gemerkten Einstellungen" auch vergessen lassen.

Absolut gilt aber auch das nicht - denn es gibt bei vielen Mainboards ja auch die Einstellmöglichkeit, das System nach einem "Power loss" ausgeschaltet zu lassen, es einzuschalten oder den letzten Zustand wiederherzustellen und dafür muß dieser letzte Zustand dann auch irgendwo gespeichert sein ... daneben KANN durchaus auch noch die letzte WoL-Einstellung liegen und ebenfalls "restauriert" werden, wenn der PC nicht gleich eingeschaltet werden soll. Das hängt dann wieder vom Mainboard und dessen BIOS ab.



Das ist jedenfalls im Ganzen ein sehr komplexes Thema und mit dem einfachen Aktivieren oder Deaktivieren einer Option irgendwo in einem OS oder dem BIOS ist es nur selten auch wirklich schon erledigt. Auch unter Windows muß man dazu meist noch im Geräte-Manager (oder mit dem passenden CLI-Programm powercfg) die richtigen Optionen setzen oder zumindest überprüfen, ob die anhand der ACPI-Daten schon korrekt eingestellt wurden.

Wenn Du hier tatsächlich die Linux-Distribution gewechselt hast (ansonsten verstehe ich nicht, WAS sich geändert haben soll), dann ist das nicht wirklich ein Mysterium, warum das dann "plötzlich" nicht mehr funktionieren könnte - jede Distro setzt nun mal unterschiedliche Schwerpunkte und damit muß man dann selbst "nacharbeiten", wenn das eine andere nicht ebenso gut beherscht, wie die zuvor genutzte. Wenn das alles erst mit der zusätzlichen Wakeup-Einstellung für Dein USB-Keyboard "zerstört" wurde (das XHC dürfte der USB-Hub sein, der nach der Liste oben Dein System aufwecken kann), dann solltest Du das einfach wieder deaktivieren (im BIOS) und versuchen, das MX-Linux so zu konfigurieren, daß es ein Aufwecken auf den Tastendruck hin unterstützt. Wenn das zusammen mit WoL gar nicht funktionieren will, mußt Du vielleicht auch einfach auf eines von beiden verzichten - Du wärst auch unter Linux nicht der Erste, der in diesen sauren Apfel beißen muß.

Das reicht auch erst mal an Text als Erklärungsversuch ... das Ermitteln, woran es letztlich tatsächlich scheitert (im Kontrast zu dem reinen Konstatieren, daß es halt nicht geht), funktioniert nur bei Dir, denn dazu braucht es auch die passende Hardware.
 
Der PC kann erwiesenermaßen WOL, der LAN-Controller des Motherboards ist zwar deaktiviert, aber stattdessen gibt es eine WOL-fähige LAN-Karte an einem PCI-Steckplatz.
Diese LAN-Karte hat ein Mini-BIOS mit automatisch immer aktiviertem WOL, das vorm Motherboard-BIOS abgefragt wird.
Inzwischen habe ich den PC auch erfolgreich per Handy (mit App namens "Wake on LAN") gestartet, dieses jedoch nur heimnetz-intern.
Es scheint auch eine Option übers Web zu geben, da habe ich aber noch nicht rausgefunden, wie und welche Daten ich wo eingeben muss.

Verfügbar sind dort:
Reference
MAC-Address
Host Name/IP-Address
Port


Die MAC ist schätzungsweise die von der LAN-Karte des Ziel-PC's und Port dürfte wohl 9 sein.
Unsicher bin jedoch bei den anderen beiden Werten.
Ich vermute, dass bei IP-Address die MyFritz-Adresse rein muss, weiß aber nicht wie,
denn wenn ich mit der Zeichenfolge anfange klappt es ebenso wenig als mit http oder https am Anfang.
Und mit Reference weiß ich leider bisher gar nichts anzufangen.
 
Meine letzten Erfahrungen mit meiner 7590 und Portweiterleitungen:
Mein zuvor mal ordentlich über eine reine UDP-Portweiterleitung funktionierendes WolCmd tut es nicht mehr, nur noch mithilfe der Option "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird.". Und da geht ja praktisch jeder Zugriff über beliebige Portfreigaben.
Diese Option hat dann noch zumindest bei mir die Eigentümlichkeit, dass eine Änderung immer erst nach einem Neustart der Box wirksam wird. So kann man sich schnell mal gewaltig täuschen.
So funktioniert mein WolCmd (Window):
Code:
wolcmd  848484848484 irgendwas.ddns.cx 255.255.255.0 57120
wolcmd [mac address] [ipaddress]       [subnet mask] [port number]

Anstelle der dyn.com-DDNS-Adresse geht selbstverständlich eine von MyFritz.
Und für eine dauerhafte ARP-Tabelle die Option "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen." setzen.
 
Der "Zielport" auf dem PC im LAN interessiert praktisch gar nicht ... da kein OS läuft und kein IP-Protokoll "verarbeitet" werden kann, ist (bei Magic-Packet) nur der Payload in der passenden Anzahl von Wiederholungen interessant. Port 9 ist nur deshalb "üblich", weil da ankommende Daten per Definition verworfen werden (deshalb heißt der Service nach RFC auch "discard") und somit tatsächlich auf irgendeinem (verwendeten) IP-Port laufende Dienste auch dann nicht durcheinander gebracht werden können (was auch per Definition schon ausgeschlossen sein sollte, ansonsten kann man mit irgendwelchen IP-Paketen den PC "abschießen"), wenn der PC bereits läuft und das vermeintliche Magic-Packet tatsächlich vom OS verarbeitet wird.

Für irgendeinen Test, ob das überhaupt funktioniert, ist der Port also vollkommen egal - selbst wenn man extern 34567 auf intern 34567 weiterleitet, sollte ein eingehendes Magic-Packet den PC wecken können. Eine IP-Adresse oder ein DNS-Name als Ziel MUSS dann selbstverständlich für den Router sein (ebenso die anzugebende Portnummer für das zu sendende WoL-Paket) - höchstens dann, wenn da irgendwo zwei Adressen angegeben werden können, muß man überhaupt "überlegen".

Ansonsten übernimmt der Router (konkret: die FRITZ!Box) bei IPv4 das Mapping der externen IP-Adresse (und ggf. das Ändern der Portnummer) auf die interne und auch das Eintragen der passenden MAC-Adresse in das (ins LAN weitergeleitete) Paket - natürlich nur im MAC-Header. Für den Payload ist weiterhin der Absender zuständig, der muß also die richtige MAC-Adresse im Magic-Packet verwenden. Damit MUSS die MAC-Adresse also an zwei Stellen stimmen - in der App UND in der FRITZ!Box.

Und da der IP-Stack eines laufenden Systems auch alles das verwerfen sollte, was keinen gültigen IP-Header hat, bringt auch das mehrmalige Benutzen des GUI-Buttons einen LAN-Client üblicherweise nicht zum Absturz - obwohl das FRITZ!OS tatsächlich nur ein Magic-Packet sendet, das aus der Zieladresse (MAC-Broadcast), der Absenderadresse (die MAC der Box), dem Ethernet-Typ (0x0842) und dem WoL-Payload (6x 0xFF + 16x MAC-Adresse des zu weckenden Systems) besteht - das wird ganz normal über ein etherwake-Binary in der Firmware gesendet und enthält GAR KEINEN IP-Header.

Man MUSS also keineswegs den "discard"-Service in irgendwelchen WoL-Paketen adressieren, weder extern noch intern ... wenn tatsächlich ein OS abstürzen sollte, weil irgendein "out of context"-Paket zufällig auf einen offenen Port am Gerät trifft, dann ist das OS (bzw. dessen Netzwerk-Stack) einfach fehlerhaft. Wer will, kann so ein WoL-Paket auch jederzeit an irgendeinen anderen Port senden, der ggf. ohnehin freigegeben ist - wenn sich auf dem PC z.B. ein HTTPS-Server befindet, der von außen erreichbar sein soll und für den daher eine Portfreigabe bereits existiert (egal, von wo nach wo die geht, zumal das bei PCP ja ohnehin nur noch Vorschläge sind, was den externen Port angeht), dann kann man problemlos auch diesen Service bzw. den dafür freigegebenen Port als Ziel verwenden. Ob mit IP-Header (von extern per Portfreigabe) oder ohne (von intern und per etherwake) ... entscheidend ist in jedem Falle der Payload des Magic-Packets und wenn das tatsächlich bis zum Netzwerk-Stack des laufenden OS gelangen sollte, dann sollte der damit gar nichts anfangen können und das Paket einfach verwerfen.

EDIT: Ach so ... Nummer 9 ist beim FRITZ!OS KEINE Option für einen extern freigegebenen (TCP-)Port. Das war früher mal möglich, aber mit der PCP-Implementierung hat da auch eine (interne) Freigabe genau dieses Ports Einzug gehalten (man kann sie auch in der Support-Datei bei den PCP-Infos finden), die obendrein wohl noch einen Filter verwendet, der nur Pakete mit einer Broadcast-Adresse durchläßt (wenn man das AVM-Protokoll-Format mal "interpretieren" wollte) - das gibt es so (meines Wissens jedenfalls) bei keinem anderen Hersteller (wobei auch kein anderer bisher PCP unterstützt, zumindest keiner, von dem ich wüßte) und ich vermute mal (anhand der Beschreibung als IGDPROBE4 - wobei das IGD für Internet Gateway Device stehen dürfte), daß da kaskadierte PCP-Server von AVM sich gegenseitig identifizieren können und ggf. auch eine Art "are you alive?" spielen, um verschiedene (oder entschlafene) PCP-Clients schon innerhalb des Timeouts für MAP- oder PEER-Requests zu erkennen. Ob auch ein Provider von seinem PCP-Server aus dann solche "probes" machen könnte, glaube ich fast nicht - denn der würde kaum mit Broadcast-Adressen arbeiten können an dieser Stelle (oder zumindest erst nach dem letzten "echten" Router, denn ansonsten flutet der ja auch sein ganzes Netz mit entsprechenden Paketen). Daher halte ich das auch für etwas, was nur in Router-Kaskaden wirklich Sinn ergeben könnte ... aber vollkommen egal, um was es sich dabei wirklich handelt: Portnummer 9 für TCP kann nicht nach extern freigegeben werden in einer FRITZ!Box mit einer FRITZ!OS-Version, die PCP verwendet.

Etwas anderes ist es ggf. bei UDP, weil IGDPROBE4 nur TCP-Pakete betrachtet ... wobei ich bei aktuellen Versionen auch nicht beschwören will, daß UDP-Freigaben für Port 9 weiterhin möglich sind. Als ich das zuletzt getestet habe (das war irgendwo bei der 06.8x, da war PCP noch "sehr frisch"), ging das jedenfalls noch und auch heute klappt das (in entsprechend alter Firmware) definitiv noch. Ob es in neueren Versionen auch noch so ist, weiß ich nicht.
 
Zuletzt bearbeitet:
Die gleiche IP zuweisen tue ich seit Jahren grundsätzlich, da ich in der Anfangszeit, als ich mit den FB's begann, auch schon einige Male "unerfreuliche Erfahrungen" mit sich ändernden IP's machen musste.

Hab's gerade noch mal getestet, sowohl MIT als auch OHNE die Option "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird."
Lief beide Male problemlos.

Da es mir im Wesentlichen darum geht, von unterwegs oder aus einem fremden WLAN heraus, meinen PC starten und steuern zu können, ohne dass sich meine Stadtwerke über den Stromverbrauch eines nonstop laufenden PC's freuen, denke ich, das inzwischen Erreichte ist eine brauchbare Lösung.
Für lokale bzw. heimnetz-interne PC-Starts mit WOL reichen die normalen WOL-Tools der entsprechenden Betriebssysteme.

Also ich gehe über Browser und MyFritz auf das FB-GUI, starte den PC warte das Hochfahren ab, was üblicherweise nach einer Minute erledigt ist und dann mache ich eine VNC-Verbindung über SSH.
Klappt recht gut auf diese Weise und scheint recht zuverlässig zu sein.

Was halt nicht geht, ist ausgehend vom Handy übers Web den PC zu starten. Dabei bin ich nicht sicher, ob AVM das in der FB blockiert hat, oder ob mein Handy, ein Galaxy S2, das inzwischen eigentlch nur noch zum Telefonieren taugt, einfach schon viel zu alt ist und daher die Version von "Wake on LAN"-App bzw. der "MyFritz"-App nicht mehr unterstützt wird.

Ich hoffe nun nur noch, dass die WOL-Starts auch unter echten Bedingungen noch laufen, da ich die Tests zwar mit dem MyFritz-Konto gemacht habe, allerdings alles nur aus dem und in das eigene WLAN, unter Verwendung der im DNS-Rebind-Schutz eingetragenen MyFritz-Adresse, wie ich ja bereits in #8 erwähnte.
 
Zuletzt bearbeitet:
Lief beide Male problemlos.
Wirklich? Auch nach einem Neustart der Fritzbox?

Außer Konkurrenz?: Über VPN geht auch ein PowerShell-Script von PeterPawn (X_AVM-DE_WakeOnLANByMACAddress ...).
Außer Konkurrenz?: WOW, gibts sogar eine App dafür.

In einem Fritzbox-Netz kann man bei deinen Tests der Realität relativ nahe kommen, wenn man das Gast-WLAN dafür benutzt.
 
... vom Handy übers Web den PC zu starten. Dabei bin ich nicht sicher, ob AVM das in der FB blockiert hat, ...
Aber Du könntest doch testen/schauen ob bzw. was aus der FritzBox kommt, wenn Du es mit dem Handy übers Web probierst, und vergleichen mit dem was an den Ziel-PC geht wenn es aus dem WLAN mit dem Handy funktioniert bzw. was aus der FritzBox kommt und an den Ziel-PC geht wenn es aus dem Web so:
Also ich gehe über Browser und MyFritz auf das FB-GUI, starte den PC warte das Hochfahren ab, ...
funktioniert.
 
Mit dem Handy geht übers Web leider gar nichts hinsichtlich des hier diskutierten Problems.
Ich komme weder mit der MyFritz-App auf die FB noch mit Browser. Mit Browser (Opera mini) geht nicht mal die MyFritz-Login-Seite auf.

Wie gesagt, ich muss mir erst ein aktuelles Handy zulegen, dann dürften damit meine Versuche deutlich erfolgreicher werden.
 

Neueste Beiträge

Statistik des Forums

Themen
246,274
Beiträge
2,249,293
Mitglieder
373,863
Neuestes Mitglied
RuthBeatty
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.