Das liegt aber nicht an AVM, sondern an den Benutzern, die ihre Geräte, die da "aufgeweckt" werden sollen, nicht vernünftig konfigurieren können.
Der Kardinalfehler beginnt nämlich bereits da, wo nicht sauber zwischen den Funktionen des OS (unter Nutzung von ACPI zum Zugriff auf die Hardware des Mainboards) und den Möglichkeiten eines speziellen BIOS unterschieden wird.
Ja, es gibt BIOS-Versionen und -Klone, die auch selbst in der Lage sind, die Hardware des Mainboards so zu konfigurieren, daß der LAN-Adapter auf ein "magic packet" hin das System startet (und zwar auch aus S5). Das ist aber eher die Ausnahme als die Regel, denn dabei sind einige Umstände (korrekt) zu beachten und heutzutage funktioniert das i.d.R. ohnehin nur noch für LAN-Adapter, die direkt auf dem Mainboard integriert sind, weil schon die Steckerleisten für die Übergabe eines WoL-Signals von einer zusätzlichen LAN-Karte an das Mainboard nicht vorhanden sind. Zwar verfügt auch jeder PCIe-Slot über ein passendes Signal, aber wie weit dieses zu berücksichtigen ist, wird eben wieder über ACPI geregelt und damit bei modernen OS mit ACPI-Support über das OS und nicht über das BIOS.
Solange man also kein Mainboard hat, bei dem definitiv auch das Starten des PC aus dem S5-Zustand (
https://de.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface) funktioniert (und das sind tatsächlich nicht sooo viele), MUSS man immer das OS richtig konfigurieren, damit das "Aufwecken" dann auch funktioniert. Und das heißt am Ende, daß das System tatsächlich nur "schlafen" darf (Sleep-Zustand) ... sonst hieße die Funktion eher "Power-On over LAN" und nicht "Wake on LAN".
Und wenn man jetzt einfach mal die eigenen Gehirnwindungen bemüht, wird einem auch sehr schnell klar werden, daß selbst für sauber funktionierendes "Aufwecken" schon noch ein paar Voraussetzungen erfüllt sein müssen. So, wie beim Menschen i.d.R. ein Wecker den "richtigen" Zeitpunkt signalisieren sollte (außer man schläft solange, bis man genug hat), muß eben ein solcher Wecker auch für den PC existieren und vor allem - das ist hier der Knackpunkt - auch über die gesamte Dauer des "Schlafes" funktionieren.
Bei einer Netzwerkkarte (oder auch einem LAN-Anschluß auf einem Mainboard) heißt das, daß sie (oder er oder "divers" - wobei ich nicht weiß, was Taucher an dieser Stelle zu suchen haben) über die gesamte Dauer des höheren Sx-Zustands (höher hier anhand der Ziffer) auch mit Strom zu versorgen ist und daß natürlich auch der "Empfänger" des Wecksignals (im "real life" der Mensch, der für erfolgreiches Wecken auch noch am Leben sein sollte) noch vorhanden ist und auf das Signal wartet. Hat der "Ohropax" eingeführt oder schläft drei Zimmer weiter und nicht neben dem Wecker, kann der Wecker sich bemühen, so viel er will - das Aufwecken wird nicht klappen.
Wer sich ein wenig mit den Sx-Zuständen vertraut gemacht hat (habe ich oben schon einmal empfohlen, iirc), der erwartet zunächst mal auch nur, daß der PC sich aus S2 oder S3 wieder aufwecken läßt durch "Wake over LAN" ... alles andere darüber hinaus, wäre reine "Zugabe" (bei S4) und bei S5 ohne BIOS-Unterstützung (und das meint nicht nur die "generelle Freigabe" des WoL, wie im zweiten Bild irgendwo weiter vorne) auch nicht möglich.
Leider gibt es immer noch zuviele fehlerhafte ACPI-Implementierungen in den verschiedensten BIOS-Versionen - wenn das Aufwecken aus S4 nicht funktioniert, ist daran aber das jeweilige Gerät schuld und nicht der Router ... und damit auch nicht AVM, was die "Beschimpfungen" in #19 einigermaßen unsinnig erscheinen läßt - zumindest richten sie sich an den falschen Adressaten.
Aber nicht zuletzt sind auch immer wieder falsche Einstellungen durch die Benutzer (u.a. auch bei solchen, die sie eben nicht richtig verstehen, wie (mit hoher Wahrscheinlichkeit) die Einstellung im ersten Bild weiter oben für das verwendete UEFI-BIOS) daran schuld, wenn sich solche "zeitabhängigen" Probleme ergeben.
Wenn ich mein System so konfiguriere, daß es nach 30 Minuten in den S3-Zustand wechselt (das wäre "Suspend to RAM", im Windows auch "Sleep" genannt - nicht mit S1 zu verwechseln), dann wird das bei den meisten Geräten (zumindest bei vielen) auch mit dem Aufwachen nach diesen 30 Minuten noch funktionieren (vorausgesetzt, ich habe auch noch den richtigen Geräten erlaubt, das System aus einem Energiesparzustand zu holen).
Wenn aber gleichzeitig noch der Wechsel nach S4 (Suspend to Disk - im Windows auch "Hibernate" (bzw. "Ruhezustand") genannt) nach einer weiteren Zeitspanne konfiguriert ist (nehmen wir mal 60 Minuten dafür an) und das System sich so weit herunterfährt, dann muß das BIOS (und das ACPI gehört zum BIOS, wenn auch zum "unsichtbaren" Teil) auch in der Lage sein, das System für das Aufwachen aus S4 korrekt zu konfigurieren, wenn es nach diesen 60 Minuten geweckt werden soll.
Wer also Probleme wie die hier oben beschriebenen hat, der sollte zunächst mal bei sich selbst suchen und nicht immer zuerst bei anderen ... wenn das Aufwachen aus S3 sauber funktioniert und aus S4 dann nicht mehr, muß man eben den Wechsel nach S4 verhindern ... selbst wenn das ein wenig mehr Energie im "Bereitschaftsmodus" verbraucht. .Wer das nicht will, muß sich eben die richtige Hardware zulegen und zwar eine, bei der das BIOS bereits in der Lage ist, selbst einen Start aus S5 zu
garantieren (und zwar über ein WoL-Paket und nicht nur über den Taster). Da muß dann eben die gesamte Hardware für ausgelegt sein - üblicherweise hat ausgewiesene "Business-Hardware" die entsprechenden Funktionen, damit Updates und Backups zentral und außerhalb der Arbeitszeit ausgeführt werden können.
Wie das eigene System sich in den verschiedenen Stromsparzuständen verhält, kann man jederzeit mit einem anderen Gerät in seinem eigenen LAN überprüfen ... wenn es auch anderen Geräten nicht gelingt, ein System aus S5 (oder selbst aus S4) per WoL zu starten, kann man wohl kaum erwarten, daß dieses dann der FRITZ!Box auf irgendeine magische Art und Weise doch noch gelingt. Erst dann, wenn so ein System nachweislich von einem anderen Gerät per WoL gestartet oder aufgeweckt werden kann und von der FRITZ!Box hingegen nicht (und hier rede ich vom "Computer starten"-Button und nicht der Automatik), dann ist der Zeitpunkt gekommen, die Schuld bei der FRITZ!Box zu suchen und sich das Ganze genauer anzusehen.
======================================================================================
AVM hat schon so manches Mal auch die WoL-Funktion "versaut" ... es ist also denkbar, daß es in einigen FRITZ!OS-Versionen tatsächlich gar nicht funktioniert. Aber für ein "geht ... geht nicht ... geht ... geht nicht" mit ein und derselben Version sollte es schon eine (am besten auch noch plausible) Erklärung geben.
Mindestens über den "Computer starten"-Button sollte sich eigentlich immer ein WoL-Paket erzeugen lassen (das kann man ja jederzeit selbst mit einem Paketmitschnitt überprüfen) ... die "Automatik" zum Wecken eines Gerätes ist sicherlich deutlich fragiler und am Ende ja eigentlich auch eher ein "Bonus" als Zusatzfunktion. Wenn das dann (meist durch Änderungen am Packet-Accelerator (PA) - also an der Art und Weise, wie Pakete "in Hardware" durch die Box geschleust werden, ohne die (schwache) CPU der Box damit zu belasten) mal nicht funktioniert, ist das zwar auch ärgerlich, aber noch lange kein Grund zum "Ausrasten".
Man darf eben nicht vergessen, daß üblicherweise für freigegebene Geräte "feste Regeln" in den Hardware-Tabellen hinterlegt werden, welche Pakete durchgereicht werden sollen und welche nicht. Werden diese weitergeleitet, erfolgt das i.d.R. direkt an das Gerät und die CPU sieht davon gar nichts ... ebenso gilt das (bei aktivem PA) für die abgewiesenen Pakete. Wenn jedes von extern ankommende Paket, das eigentlich gar nicht "angefordert" wurde (also keine Antwort im Rahmen einer ausgehenden Verbindung ist), erst durch den Flaschenhals zwischen dem (internen) Switch und der CPU müßte, wäre es sehr einfach, eine FRITZ!Box zu überlasten (an einem Anschluß mit entsprechenden Datenraten).
Wenn man jetzt ein Netzwerkgerät bei eingehendem Verkehr automatisch wecken lassen will, muß ja irgendjemand das dazu notwendige Netzwerkpaket (als "magic packet") erst mal erzeugen ... das wird i.d.R. die CPU sein (ich kenne jedenfalls keine Spezifikation für ein Router-SoC, wo das eine Hardware-Funktion ist - Gegenbeispiele nehme ich aber gerne). Dazu muß diese aber erst mal davon in Kenntnis gesetzt werden, daß jetzt ein Zugriff auf ein solches Gerät erfolgen soll ... die (eingehenden) Pakete müssen also (immer noch unter der Annahme, daß der PA eingeschaltet ist) mindestens mal zur CPU gespiegelt werden, damit diese davon Kenntnis erhält.
Im schlechtesten Fall benutzt man dann für eingehende Verbindungen zu einem solchen Gerät den PA gar nicht mehr, damit müßte dann JEDES Paket in dieser Verbindung durch die CPU, was den Durchsatz entsprechend niedrig hält. Im besten Fall programmiert das FRITZ!OS eine direkte Weiterleitung der Pakete mit Spiegelung an die CPU nur dann, wenn es davon ausgeht, daß das betreffende Netzwerkgerät ein "magic packet" braucht, um wieder seine Arbeit aufzunehmen und schaltet dann (wenn das Gerät wieder läuft) die Spiegelung zur CPU (aus Performance-Gründen) wieder ab, solange das Gerät arbeitet.
Hier ist die Behandlung von TCP-Verbindungen natürlich wieder leichter, wenn man davon ausgeht, daß das Gerät beim "Schlafengehen" zuvor alle offenen TCP-Verbindungen sauber beendet und damit auch der Router mitbekommt, daß das Gerät jetzt keine aktiven Verbindungen mehr hat und man bei der nächsten eingehenden Verbindung (schon "prophylaktisch" bei einem SYN-Paket) ein WoL-Paket vorausschicken sollte. Bei UDP kann man das nur mit entsprechenden "Timeouts" machen (wenn für eine bestimmte Zeit keine Daten mehr in dieser Verbindung transportiert wurden, wird sie als "beendet" angesehen), weil es dort keine explizite "Beendigung" einer Verbindung gibt (ja, eigentlich gibt es nicht mal "Verbindungen" dort). Bei UDP müßte man also wieder alle Pakete durch die CPU leiten oder zumindest zu ihr spiegeln, weil es ein spezifisches Merkmal wie das SYN-Flag beim TCP für eine "neue" Verbindung gar nicht gibt. Hier wären also UDP und TCP auch wieder getrennt zu behandeln.
Beim Aufwecken über den "Computer starten"-Button ist das alles wieder einfacher ... erstens hat man einen eindeutigen Trigger (eben den Druck auf den Button) und zweitens wird dieser Trigger ohnehin auf der CPU verarbeitet - diese kann (und wird) hier also einfach das Paket zum Aufwecken erzeugen. Die Konditionen, wann man nun ein Paket zum "automatischen Wecken" senden sollte und wann nicht (es macht ja auch keinen Sinn, JEDES eingehende Paket mit einem zusätzlichen WoL-Paket zu versehen), sind eben deutlich komplizierter ... am sichersten dürfte das noch funktionieren, wenn man den PA generell abschaltet (sollte auf der Support-Seite ja möglich sein) - nur verliert man dadurch eben auch an Durchsatz, aber die CPU "sieht" damit auch jedes eingehende Paket.
Daß das mit dem PA generell nicht immer so ganz einfach ist, sieht man schon daran, daß immer wieder mal Probleme auftauchen in der Firmware, die mit diesem in Verbindung stehen - auch die Tatsache, daß in Paketmitschnitten auf dem WAN-Interface gerne mal Daten fehlen, ist ja i.d.R. darauf zurückzuführen, daß entweder die Spiegelung zur CPU bei aktiviertem PA nicht eingeschaltet wurde oder daß der PA nicht (generell) abgeschaltet wurde und damit automatisch jedes Paket über die CPU muß.
Wer also die Ursache für nicht funktionierendes, automatisches Aufwecken in der FRITZ!Box suchen möchte, der sollte als Erstes mal den PA deaktivieren und prüfen, ob das Problem damit behoben ist. Das sollte zwar kein Dauerzustand sein, aber daß bei der Programmierung der (closed source-)Komponenten des AVM-WAN-Stacks auch gerne mal mit dem Gesäß etwas eingerissen wird, was zuvor mit den Händen aufgebaut wurde und funktioniert hat, ist ein offenes Geheimnis und (deutlich mehrfach) hier auch oft genug festgestellt im IPPF.
Zwar kennen wir alle den Quelltext für diese Komponente (dsld bzw. kdsldmod.ko) nicht, aber man kann schon anhand von alten Funktionsnamen in den (notwendigerweise) exportierten Symbolen darauf schließen, daß da jede Menge - teils uralter - Schrott mit "durchgezogen" wird und ich rate mal, daß jeder Software-Architekt einen Herzkasper kriegen würde, wenn er das zum ersten Mal sieht (und den Aspekt des "ist historisch gewachsen" nicht berücksichtigt). Aber AVM ist ja auch dort etwas am "Aufräumen" und "Entwirren", wie man schon daran sehen kann, daß jetzt das VPN in einen eigenen Daemon wandert.
========================================================================================
EDIT:
Wer sich noch einmal genauer mit den "Schlafzuständen" von Windows befassen und herausfinden will, was diese mit der Fähigkeit zum "Wake on LAN" zu tun haben, der kann ja mal diese Seite besuchen:
Erfahren Sie mehr über die Systemleistungszustände, die der ACPI-Spezifikation (Advanced Configuration and Power Interface) entsprechen.
docs.microsoft.com
- da findet sich (am Ende) auch der Hinweis, daß ein Aufwachen aus S5 mit Windows nichts zu tun hat und nur Sache des BIOS/der Hardware ist.
Auch die Tatsache, daß "fast startup" (System wird neu gestartet und dann dieses "frisch gestartete System" als "Ruhezustand" gesichert beim "Herunterfahren" bzw. der Benutzer wird abgemeldet vor dem "Ruhezustand") unter Windows das ACPI so programmiert, daß ein WoL nicht möglich ist, kann man dort noch einmal nachlesen. Hier helfen also manchmal schon die richtigen Einstellungen unter Windows und das sind beileibe nicht immer die Standardeinstellungen - m.W. ist nämlich "fast startup" zumindest unter Windows 10 der Standard. Wie man das dann deaktiviert ("fast startup" oder auch "fast boot"), ist in diversen "Tipps" im Internet hinreichend beschrieben ... manchmal hilft schon diese "Kleinigkeit", damit ein System sich auch aus S4 starten läßt.
