[WOL] Wake on Lan non fonctionnel après avoir tout essayé (DynDNS) Windows 10/11

[backnd]

Bonjour à tous,

 

Je viens recueillir votre aide car je n'ai jamais réussi à faire fonctionner le Wake On Lan en WAN afin d'allumer mon ordinateur depuis mon smartphone, ce qui est plutôt utile quand je suis en déplacement et que j'ai besoin d'allumer rapidement mon PC pour répondre à une demande urgente.

 

Je précise que je suis sous Windows 11 et que le problème était le même sous Windows 10.

 

Cette problématique est à titre professionnel : besoin d'entreprise / ordinateur d'entreprise.

Mon ordinateur d'entreprise est mon ordinateur personnel.

 

Hier, je me suis remis à tout vérifier et refaire les manipulations depuis le départ.

Pour les personnes ayant le même problème que moi et afin de vous aiguiller le plus possible, je vais tenter de vous faire le post le plus complet possible avec un maximum de détails sur toutes mes manipulations.

 

Matériel :

Windows 11 Professionnel 21H2

Ordinateur custom (CM : Asus ROG Strix B550-A, CPU : R5-5600X, GPU : RTX 3080 FE, 16 Go RAM)

Tous les pilotes sont mis à jour régulièrement depuis le site du constructeur : BIOS, CM, CPU, RAM, GPU, chipset, audio, carte réseau.

 

Réseau :

Livebox 4 Orange (particulier)

Raccordement en fibre optique

Alimentation Ethernet : Livebox > prise murale > switch Netgear GS308E (8 ports) > ordinateur

Adresse IP locale : statique (IP : 192.168.1.X, masque : 255.255.255.0, gateway : 192.168.1.1 ; DNS : 8.8.8.8 / 1.1.1.1)

 

Etant donné que l'attribution d'une IP publique statique coûte 18€ chez Orange, je préfère passer par No-IP afin d'avoir un DynDNS.

Ce dernier remonte correctement dans dans ma box (après redémarrage via l'interface).

 

 

Dans un second temps, j'ai effectué la redirection de port dans mes règles NAT :

 

 

Allez savoir pourquoi Orange met "unix" en équipement, alors que ce n'est pas le cas. Mais la box aime faire ce qu'elle veut...

Quoi qu'il en soit, vous verrez que ça ne change rien.

 

Dans mon BIOS, j'ai activé les paramètres de Magic Packet et autorisé le réveil via les ports PCIe (carte réseau).

J'ai également testé avec et sans le Fast Boot (démarrage rapide).

 

Dans Windows 11, j'ai bien activé les options de Magic Packet de ma carte réseau Ethernet 1 via le gestionnaire de périphériques :

 

 

Wake on Magic Packet depuis S0ix est également activé mais je ne sais pas ce qu'il signifie (état S0 donc arrêt total ? ix ?).

 

Etant donné que Windows 11 ne propose plus le mode Hibernation (= veille prolongée), l'option était tout simplement absente de l'ordinateur.

J'ai donc entré la commande dans le terminal en tant qu'administrateur pour recouvrir l'option : 

 

powercfg /h /type full

 

J'ai ainsi pu afficher et cocher Veille prolongée.

 

 

Néanmoins, et pour ce point j'attire votre attention, je ne sais pas si je dois régler ma mise en veille prolongée, qui pour le moment est à "Jamais".

Je précise que je préfère que mon ordinateur ne se mette jamais en veille sans mon autorisation (ça interrompt des programmes qui tournent en continu).

 

 

J'utilise comme application Android de Wake on Lan : WolOn - Wake on LAN Widgets (qui semble bien fonctionner pour tous les utilisateurs : notation 4,7/5 sur 5000 avis).

Je fais aussi mes tests avec d'autres applications pour éliminer les faux positifis (faux négatifs dans mon cas...).

 

De plus, j'ai vérifié que les états d'alimentation étaient bien disponibles (information trouvée sur un forum, je n'ai pas encore bien compris le concept de chaque état) :

 

powercfg -a

 

Parait-il que l'état à posséder est S3, ce qui est le cas.

Est-ce vrai ? est-ce que les autres états indisponibles peuvent venir interférer avec le WOL ?

 

 

Petite précision hardware mais qui peut faire la différence, ma carte réseau est bien alimentée quand mon PC est éteint (LED allumée sur le switch et l'ordinateur).

 

Ce matin, je me suis dit... Si je sniffais ma connexion sur Ethernet 1, PC allumé, pour vérifier si le paquet magique arrive bien à destination ?

J'ai donc utilisé Wireshark en envoyant un paquet magique wia le WAN.

Le résultat est positif. Le paquet arrive bien à destination en passant par le DDNS No-IP, puis en redirigeant le paquet vers mon ordinateur via le port 99 spécifié et l'adresse MAC inscrite dans la trame IP.

 

 

J'espère avoir donné toutes les informations nécessaires pour investiguer mais dans le cas d'un oubli, n'hésitez pas à me le faire savoir.

J'aimerais donc, vous l'aurez compris, déceler pourquoi le Wake on Lan ne fonctionne toujours pas malgré tous ces paramètres et vérifications (Wireshark).

 

Précisions :

Je n'ai pas encore testé en LAN mais c'est au programme ;

Je souhaite démarrer mon PC depuis mon smartphone et ne fais donc pas de test depuis un autre ordinateur.

 

En vous remerciant par avance pour votre aide,

Je vous souhaite une bonne semaine.

[Steph69]

Ta config semble correcte, l'affectation de bail statique contournant le problème de flush ARP.

 

Est tu sur du port 9 UDP, habituellement c'est plutôt le 7 UDP ?

 

Il faudrait quand mêle faire le test en local pour vérifier (genre depuis l'appli du tel en WIFI sur la box, idéalement en broadcast pour éliminer tout doute)

[backnd]

Merci pour ta réponse Steph.

 

Le port 9 est privilégié pour un envoi WAN contrairement au port 7 davantage destiné au LAN.

Sur Windows 10 j'avais monté deux règles NAT pour les deux ports, ça ne fonctionnait pas mieux.

[Bastien I²]

Bonjour,

 

Pour ma part, ça fonctionne bien avec une appli android sous Windows 10, en veillant bien effectivement à mettre l'ordi en veille prolongée.

Il faut d'abord tester en local, et si ça fonctionne, essayer via l'accès que tu as ouvert dans la box. Tant qu'en local ça ne fonctionne pas, ça ne sert à rien d'aller plus loin.

 

Bonne chance.

[backnd]

Bonjour Bastien,

 

En effet, je vais effectuer le test ce soir.

Lorsque je clique sur "Arrêter", comment dans quel état se met l'ordinateur ? S0, S1, etc.

 

Il est probable que ce dernier se mette dans un état non veille prolongée qui ne permet pas au paquet de transiter jusqu'à lui mais je ne sais pas comment le vérifier.

[Steph69]

Y'a la solution des familles sinon, la prise connectée !

 

On règle dans le bios un "After PowerLoss" => "Démarrage"

Dans l'appli de la prise un simple Off/on fait démarrer le PC, et ça évite en plus d'utiliser la veille prolongée.

 

[backnd]

Je vois ce que tu veux dire, ce doit être le même principe que pour ma lumière du salon

Néanmoins je persévère et veux comprendre ce qui ne fonctionne pas avec le WOL.

[Steph69]

Alors le conseil commun est de le faire fonctionner en réseau local avant de basculer cela en WAN

[Bastien I²]

Non il faut bien choisir « Mettre en veille prolongée » au lieu de «  arrêter » dans le menu marche /arrêt 

J’ai jamais réussi à le faire marcher autrement ; c’est peut être possible mais j’imagine que ce doit être géré au niveau de la carte mère.

 

 Tout à fait @Steph69 je te rejoins là dessus, il ne faut pas mettre la charrue avant les bœufs.

[backnd]

Bastien, tu m'apportes là une information importante ! je ne le savais pas.

Etant donné qu'on peut le faire PC "arrêté", je pense qu'il faut manipuler la base de registre pour convertir l'état de l'ordinateur lors de l'appui sur Eteindre.

Je vais creuser de ce côté et comme vous l'avez dit je vais tester en local dans un premier temps.

[backnd]

De retour ! Bon, et bien merci pour cette astuce, ça fonctionne en WAN en arrêtant le PC via la veille prolongée.

 

Peut-on également faire fonctionner de la même manière avec Arrêter en modifiant une clef de registre qui modifierait l'état d'alimentation SX ?

 

[Pyrithe]

Je dirai que le WoL, pour fonctionner sur une machine en arrêt, doit être configuré dans le BIOS.

 

Attention en se basant sur un fonctionnement exclusivement en veille prolongée. Dans ce mode, les GPO ne s'appliquent pas, etc. On créer un court circuit de ce qui doit s'appliquer lors d'un démarrage normal.

[backnd]

Pyrithe, j'ai bien pris note de ton commentaire.

 

J'ai déjà activé Wake on Lan dans mon BIOS, tout comme le réveil par PCIe et ça ne permet pas un démarrage WOL depuis le mode arrêt complet.

 

Pour info, contrairement à ce qu'on voit partout sur internet, le Fast Boot semble ne pas interférer étant donné que le miens est activé (du moins pour le réveil depuis le mode hibernation).

 

Dans les paramètres de ma carte réseau Ethernet 1 j'ai également l'option Wake on Magic Packet depuis S0ix (cf. screenshot dans le premier message).

 

Cela pourrait-il dire qu'on peut réveiller le PC depuis le mode arrêt complet ?

Que signifie "ix" après S0 selon vous ?

 

Je pense qu'étant donné que la carte réseau reste active même en état arrêt complet, il y a moyen de démarrer via le WOL. Reste à trouver comment.

 

Je fais des recherches de mon côté et posterai mes résultats.

[backnd]

Alors, pour répondre répondre à mes propres questions (j'ai potassé !) :

 

L'état de mise en veille prolongée que je peux initier est S4. C'est l'état où le plus de composants sont éteints juste avant l'état S5 signifiant l'arrêt complet.

 

Sur Windows 11, la veille prolongée à été désactivé à profit de la veille hybride mais je ne me suis pas encore documenté sur cette dernière. Mais comme je l'ai fait, il est possible de réintégrer la veille prolongée.

 

L'hibernation (veille prolongée) et la veille hybride sont toutes deux sous l'état S4.

 

Pour les versions de Windows 10 antérieures à la 1809 (1709 et moins), l'état S5 permettait un redémarrage via WOL.

 

La désactivation du démarrage rapide (fast boot) concernait les anciennes versions de Windows 10 mais ne s'applique plus aujourd'hui. Le WOL fonctionne avec le fast boot activé (testé et approuvé).

 

Seuls les systèmes compatibles ACPI peuvent réveiller un PC en S5.

Les systèmes compatibles APM peuvent réveiller un PC en mode S3 (veille) et S4 (hibernation).

 

APM est l'ancienne norme d'économie d'énergie qui donnait au BIOS la responsabilité de gérer les composants et leurs états de fonctionnement.

 

ACPI datant de 1996 et revue en 2016 vise à donner au système d'exploitation la responsabilité de gérer les composants et leurs états de fonctionnement.

 

Sur certains modèles de cartes mères répondant à la norme APM par défaut, il est possible de transiter vers ACPI depuis le BIOS.

 

À l'inverse, toutes les machines récentes sont régies par la norme ACPI mais selon les machines, il est possible via le BIOS d'activer APM, qui reste une norme plus fiable. Attention néanmoins aux pilotes utilisés.

 

L'état S0ix appartient à la nouvelle norme d'états d'alimentation établie par Intel en accord avec AMD, pour un écosystème davantage normalisé depuis Windows 10.

 

On parle ici uniquement de l'état S3 (veille) !

 

Cette nouvelle norme "Modern Standby" vient accélérer la reprise d'activité depuis un état de veille S3.

 

Citation depuis docs.microsoft :

 

"Lorsque les systèmes compatibles Modern Standby entrent en veille, le système est toujours en S0 (un état de fonctionnement complet, prêt et capable de travailler). Les applications de bureau sont arrêtées par le modérateur d'activité de bureau (DAM) ; cependant, les tâches en arrière-plan des applications Microsoft Store sont autorisées à fonctionner. En veille connectée, le réseau est toujours actif et les utilisateurs peuvent recevoir des événements tels que des appels VoIP dans une application Windows Store. Bien que les appels VoIP entrant via Wi-Fi ne soient pas disponibles en mode veille déconnecté, des événements en temps réel tels que des rappels ou la synchronisation d'un appareil Bluetooth peuvent toujours se produire."

 

Pour en revenir au WOL...

 

- Pour que le PC puisse être démarré via WOL en S5, il est nécessaire de laisser la carte réseau allumée (normalement éteinte en S5). Dans le BIOS on trouve une option ressemblant à "Power On By PCIE Devices" ; la carte réseau étant un périphérique PCIe.

 

Dans mon cas, cette étape est déjà faite mais je ne peux pour autant pas réveiller mon PC depuis l'état S5.

 

- Ajouter une entrée statique à la table ARP.

L'état S4 conserve ces paramètres dans le fichier système créer au moment de l'hibernation, tandis que S5 flush la table ARP et ne permet donc plus à un paquet WOL entrant de trouver son destinataire via la MAC, étant donné que le reset de la table ARP du routeur perdra les informations MAC/IP de la machine éteinte.

 

Solution contournable sur certains routeurs en ajoutant une entrée ARP statique.

 

Je ne sais pas si le bail DHCP statique permet de conserver l'association MAC/IP mais c'est une solution envisageable étant donné que l'entrée se fait également sur le routeur.

 

N'hésitez pas à me donner votre avis sur ce que j'ai dit. Rien n'est copie-collé sauf la source de Microsoft citée.

 

Ma restitution de ce que j'ai pu comprendre peut parfois être erronée alors pensez à me corriger si c'est le cas !

[nobru]

Il y a 22 heures, Steph69 a dit :

Y'a la solution des familles sinon, la prise connectée !

 

Bonjour,

 

Des conseils de prises connectées ?

Certaines ne marchent qu'en local ou bien marchent-elles toutes via internet ?

Merci

[backnd]

Perso j'ai une Kasa qui fonctionne en LAN et WAN.

[Steph69]

On sort du sujet initial

En prise connectées il en existe a un nombre énorme, avec normes, puissances, fonctionnalités, intégration différents.

Ça dépend de l'utilité, de l’écosystème déjà en place, etc.

 

sinon

Citation

Solution contournable sur certains routeurs en ajoutant une entrée ARP statique.

 

Je ne sais pas si le bail DHCP statique permet de conserver l'association MAC/IP mais c'est une solution envisageable étant donné que l'entrée se fait également sur le routeur.

 

Normalement le bail statique permet de garder l'association, après ce n'est pas vrai pour tous les routeurs (A tester car trouver cette info dans la documentation relève du miracle)

Certains routeurs permettent sinon de faire un NAT sur l'adresse de broadcat, c'est une solution qui marche aussi (pas une livebox)

 

Sinon à l'époque ma Box Bouygues avait une fonctionnalité de proxy WOL qui fonctionnait très bien.