Quitter le forum et retourner au site

Le réveil par réseau

Vous avez un didactiel ou une astuce particulière concernant un logiciel, partagez votre expérience dans cette partie.
Avatar de l’utilisateur
le Manchot Masqué
Administrateur du site
Messages : 719
Inscription : lun. 26 mai 2008, 21:05
Distribution : Debian, Ubuntu
Niveau : Moitié plein !
Localisation : Guebwiller

Le réveil par réseau

Message par le Manchot Masqué »

Le réveil par réseau ou "wake on lan" (wol pour les intimes) permet de réveiller des machines éteintes à distance, via un petit paquet réseau spécial, envoyé de la machine allumée M1 vers la machine éteinte M2.

Il utilise l'un des deux mécanismes suivants :
- le mécanisme halt/reboot si M2 est arrêtée
- le mécanisme suspend/resume si M2 est en veille

La mise en œuvre de l'outil dépend :
- du matériel - et notamment du bon vouloir du constructeur à respecter les normes en place
- du système d'exploitation utilisé - ici une machine sous Ubuntu 16.04 LTS avec un kernel 4.4

1 / Sur la machine M2 réglage du BIOS

Comme souvent, la mise en œuvre commence dans le BIOS de la machine, en pressant soit la touche F2 sur un portable, soit la touche SUPPR sur un fixe. A noter que cette touche peut changer : exemple chez sony avec une touche dédiée à part.

Un autre problème des BIOS est que chaque constructeur fait sa petite tambouille perso. De ce fait, les intitulés suivants seront à adapter à votre configuration propre - désolé !

Après avoir passé la langue en français, les réglages sont les suivants :
- dans Settings\Avancé\périphériques intégrés
- Contrôleur LAN [Activé]
- Option ROM LAN [Activé]
- dans Settings\Avancé\Paramètre des actions de reprise
- reprise par [BIOS]
- reprise par périphérique PCI-E [Activé]
- reprise depuis S3 par les périphériques [Activé]

Puis c'est la touche F10 pour sauvegarder les options et redémarrer la machine.

2 / Sur la machine M2

Bien évidemment, une fois Ubuntu démarrée, on ouvrira un terminal, et on se mettra en super-utilisateur avec

Code : Tout sélectionner

sudo -s
pour taper la suite des commandes...

On recherche tout d'abord le nom de la carte réseau côté kernel.

Code : Tout sélectionner

# ip a

1: lo: ...
2: enp2s0: ...
Les habitués auront constaté que l'interface réseau n'est pas ethX mais enp2sX, tout simplement parce que depuis les kernel 4.X, la méthode de nommage des interfaces réseaux a changé.
Le but ici n'étant pas de rentrer dans les détails, nous retiendrons simplement l'interface qui nous intéresse, soit enp2s0.

On passe ensuite par ethtool :

Code : Tout sélectionner

# ethtool enp2s0
Settings for enp2s0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/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
Les deux lignes qui nous intéressent ici sont :

Code : Tout sélectionner

	Supports Wake-on: pumbg
	Wake-on: g
La première montre les options possibles pour la carte réseau (une lettre par option). La seconde ce qui a été réglé.

Si vous obtenez ici

Code : Tout sélectionner

	Wake-on: d
C'est que quelque chose ne va pas... On va se placer dans ce cas de figure pour la suite (sinon ce serait trop simple voyons !).

Vous pouvez alors essayer de mettre l'option 'g' (sortie de veille via un paquet "magique") manuellement avec la commande :

Code : Tout sélectionner

# ethtool -s enp2s0 wol g
puis retester avec :

Code : Tout sélectionner

# ethtool enp2s0
Ça doit normalement marcher sans problème, sauf que cette manière de faire est temporaire, et ne sera pas conservée au prochain redémarrage.

Une autre solution avancée par certains consiste à rajouter à /etc/rc.local la ligne

Code : Tout sélectionner

/sbin/ethtool -s enp2s0 wol g
avant la ligne

Code : Tout sélectionner

exit 0
Ce script, bien connu des habitués, est lancé une fois au démarrage de la machine, après tous les autres scripts.
Malheureusement, il n'est pas relu lors d'une sortie de mise en veille.
Ce n'est donc pas non plus la bonne manière de faire...

Une troisième solution avancée sur les forums est de modifier /etc/network/interfaces avec des lignes du type :

Code : Tout sélectionner

auto enp2s0
iface enp2s0 inet dhcp
   up ethtool -s enp2s0 wol g
   down ethtool -s enp2s0 wol g
On remarquera les options up et down pour forcer une commande spéciale à l'allumage/extinction de la carte réseau visée.
Mais là encore, on se heurte exactement au même problème que précédemment : les interfaces réseaux sont lues au démarrage de la machine, et non en sortie de veille...

En outre, dans cette manière de faire, fixer les réglages dans /etc/network/interfaces court-circuite par défaut le network-manager, qui permet de contrôler graphiquement les interfaces réseaux, ce qui risque de déstabiliser les usagers novices...
A noter que cette manière de faire est aussi plus "orientée" vers les machines fixes que vers les ordinateurs portables, car mettre une configuration fixe, dans un appareil nomade, n'est généralement pas une bonne idée à l'usage...

Si le WOL apparaît toujours avec l'option 'd', il faut éditer /etc/default/tlp et rechercher la ligne :

Code : Tout sélectionner

WOL_DISABLE=Y
et la changer en :

Code : Tout sélectionner

WOL_DISABLE=N
En effet, si vous laissez la première option, cela signifie que vous ne pourrez utiliser le réveil par réseau quand la machine est en veille, et ce alors que le réveil par réseau pourra parfaitement fonctionner ordinateur éteint !

De la même manière pour l'extinction de la machine cette fois, un autre fichier qu'il peut être intéressant de modifier est le /etc/init.d/halt et notamment l'option :

Code : Tout sélectionner

NETDOWN=yes
en

Code : Tout sélectionner

NETDOWN=no
histoire de laisser la carte réseau allumée.

3 / Tests depuis la machine M1 :

La machine étant également sous Ubuntu 16.04, on installe paquets nécessaires :

Code : Tout sélectionner

apt install etherwake wakeonlan
Un petit

Code : Tout sélectionner

arp -v 
va permettre d'afficher la table ARP, et notamment de repérer l'adresse MAC de la carte réseau sur la machine M2, qui doit apparaître sous la forme XX:XX:XX:XX:XX:XX.

C'est cette adresse MAC qu'il faudra utiliser sur la machine M1, avec les commandes :

Code : Tout sélectionner

# etherwake XX:XX:XX:XX:XX:XX
ou

Code : Tout sélectionner

# wakeonlan XX:XX:XX:XX:XX:XX
Le test doit tenir compte des deux modes de configuration possibles.

Dans un premier temps, il s'agit de tester le mode halt/reboot. On éteint donc la machine M2, et on lance les commandes précédentes sur la machine M1. La machine M2 doit alors s'allumer.

Si tout s'est bien passé, on peut passer au second mode suspend/resume, en mettant cette fois la machine M2 en veille mémoire (état BIOS S3, ou pm-suspend en console root sur la machine M2). On relance les commandes précédentes sur la machine M1, si tout se passe bien, M2 doit sortir de veille.

4 / Conclusion

L'allumage d'une machine distante, via un paquet réseau qualifié de "magique" dans la littérature, est rarement une sinécure dans la pratique.
Elle nécessite une certaine compréhension technique des mécanismes de mise en veille d'un ordinateur, et demande pas mal de réglages sur la machine distante.

Sur ce point, GNU/Linux et Windows se valent : il n'est pas rare en effet de devoir mettre les mains dans le cambouis, avant de réussir enfin à trouver la configuration optimale.
L'avantage reste cependant à GNU/Linux, toujours pour la même raison : en cas de problème, l'OS libre permet en effet de "suivre" et de tester ce qui se passe beaucoup plus facilement !

En tout cas, si vous avez un serveur qui fait trop de bruit ou prend trop de place, cette fonctionnalité peut vous permettre de déplacer le problème, et de travailler depuis votre machine principale en toute sérénité, en allumant la machine M2 uniquement quand vous en avez besoin. La mise en veille, c'est aussi bon pour la planète...
Avatar de l’utilisateur
gerard25
Messages : 175
Inscription : dim. 12 févr. 2012, 15:33
Distribution : ubuntu 22.04MATE
Niveau : petit initié sur UBUNTU
Localisation : Grand Charmont

Re: Le réveil par réseau

Message par gerard25 »

Bonjour et Meilleurs Voeux à Toutes et Tous pour cette Nouvelle Année

Est ce que ce type de conditionnement d'une machine pour la réveiller à distance peut etre réalisé par un tiers distant
sans que cela se remarque ?

Gerard
Avatar de l’utilisateur
le Manchot Masqué
Administrateur du site
Messages : 719
Inscription : lun. 26 mai 2008, 21:05
Distribution : Debian, Ubuntu
Niveau : Moitié plein !
Localisation : Guebwiller

Re: Le réveil par réseau

Message par le Manchot Masqué »

Meilleurs Voeux également.

Pour répondre à votre question, à partir du moment où vous avez des firmwares fermés dans un appareil, tout est possible, même en utilisant un autre élément actif du réseau.

Et n'allez pas croire qu'un matériel professionnel est plus sécurisé : on ne compte plus les failles volontaires ou non, largement exploitées par les services de renseignement...
Répondre