Vous n'êtes pas identifié.
Après avoir passé plusieurs heures voir semaines à deux personnes sur ce sujet je poste ce problème sur notre forum:
Pour les deux machines mentionnées dans le titre de cette discussion impossible d' effectuer un WOL avec emission du Magic Packet sur le même réseau local malgré que ethtool mentionne que WOL avec Magic Packet est activé.
W253EU
selon lshw:
-network
description: Ethernet interface
produit : RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
fabricant: Realtek Semiconductor Co., Ltd.
W650SZ
selon lshw:
-network
description: Ethernet interface
produit : RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
fabricant: Realtek Semiconductor Co., Ltd.
Conclusions il s'agit du même Ethernet Controller
Pour les deux machines:
selon sudo ethtool eth0 :
Supports Wake-on : pumbg
Wake-on : g
Historique des sites et pages web consultés:
https://doc.ubuntu-fr.org/wakeonlan
http://ubuntuforums.org/showthread.php?t=2233674 sans résultats
http://ubuntuforums.org/showthread.php?t=2308059 sans resultats
https://packages.debian.org/de/sid/all/r8168-dkms sans resultats
http://askubuntu.com/questions/134841/r … ake-on-lan
http://askubuntu.com/questions/747378/s … for-ubuntu
et bien d'autres....
Malheureusement aucune des pistes n'a abouti pour le moment
Toute aide est la bienvenue
Merci d'avance
Hors ligne
Bonjour,
J'ai juste lancé une requête "system76 wake on lan" pour voir si la question s'était déjà posée avec des portables Clevo de chez System76.
Parmi les premiers résultats, j'ai trouvé:
http://ubuntuforums.org/showthread.php?t=2308059
http://www.todownloads.net/forumdisplay.php?f=341
En resserrant la recherche sur "system76 wake on lan RTL8111/8168/8411", on trouve encore:
http://www.hivmr.com/db/fcmdm38f9kaf9s7 … fas91jsdsc
https://debian-facile.org/viewtopic.php?id=11859
Peut-être une piste?...
Cordialement.
Hors ligne
Je ne suis pas sûr d'avoir compris le problème.
L'idée, c'est de permettre le WOL sur les machines citées en titre ?
Quoi qu'il en soit, le WOL agit très bas sur le matériel.
Pour que ça marche il faut que que le matériel le supporte.
N'y a-t il pas une réglage idoine dans le BIOS qui permet d'enclencher la prise en charge du Wake On Lan sur ces 2 machines ?
J'ai plusieurs machine pour lesquelles c'est le cas.
Hors ligne
Bonsoir Eggman,
En effet, pour pouvoir enregistrer une certification Energy Star V6.0 auprès de l'UE pour ces deux machines, il nous faut pouvoir attester du bon fonctionnement du WOL. Cette condition est remplie avec l'OS Windows 7, 8.2 ou 10, mais pas avec Ubuntu 14.04, ni même avec aucune version ultérieure!...
Selon ma compréhension de non-informaticien, on ne peut donc incriminer ni le BIOS (aucun réglage possible) ni la carte Ethernet. Le problème vient donc du noyau Linux et/ou du pilote de la carte Realtek RTL8111...
Voilà bientôt un an qu'on est bloqué par cette histoire. Alors toute bribe de solution sera bienvenue!...
Hors ligne
Bonjour,
Dans une de mes machines, le BIOS ne me permet pas de configurer le démarrage par réseau.
Par contre, il me permet d'autoriser le réveille de la machine par les cartes PCI et PCI-Express (j'ai activé les 2 dans le doute).
Pour activer le démarrage par paquet magique, j'ai essayé les informations données sur le wiki d'ArchLinux et ça a marché.
J'utilise Network-Manager, alors j'ai suivi cette section spécifique.
Pour voir si l'écoute réseau est active :
sudo nmcli c show eth0 | grep 802-3-ethernet.wake-on-lan
Si c'est à "default", alors il faut l'activer :
sudo nmcli c modify eth0 802-3-ethernet.wake-on-lan magic
Il est dit qu'il faut peut-être redémarrer 2 fois. Pour moi, ça a marché du premier coup (la valeur de la première commande retourne "64 (magic)") et j'ai bien pu démarrer ma machine à distance.
PS:
Désolé, je n'avais pas vu que vous aviez déjà essayé ethtool. Je vois dans votre premier poste que la valeur retournée par ethtool est à "g", un paquet magique devrait pouvoir démarrer votre machine.
Dernière modification par Trim (19 Mar 2016 15:12:17)
Hors ligne
Bonjour à tous,
D'abord merci à tous ceux qui ont répondu.
Dans notre assortiment nous avons également une machine W670SZ
ordinateur selon la commande lshw :
w670szq1
description: Ordinateur portable
produit: W65_67SZ (Not Applicable)
fabriquant: Notebook
version: Not Applicable
numéro de série: Not Applicable
bits: 64 bits
fonctionnalités: smbios-2.7 dmi-2.7 vsyscall32
carte mère selon la commande lshw:
*-core
description: Carte mère
produit: W65_67SZ
fabriquant: Notebook
identifiant matériel: 0
version: Not Applicable
numéro de série: Not Applicable
emplacement: Not Applicable
Bios selon lshw :
*-firmware
description: BIOS
fabriquant: American Megatrends Inc.
identifiant matériel: 0
version: 1.03.06
date: 06/25/2014
taille: 64KiB
capacité: 4032KiB
Chipset network selon lshw
*-network
description: Ethernet interface
produit: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
fabriquant: Realtek Semiconductor Co., Ltd.
identifiant matériel: 0.1
information bus: pci@0000:05:00.1
nom logique: eth0
version: 12
numéro de série: 80:fa:5b:26:1c:bf
bits: 64 bits
horloge: 33MHz
Et pour cette machine le WOL fonctionne
Pour la machine W650SZ
les paramètres selon lshw sont identiques sauf:
Chipset network selon lshw
*-network
description: Ethernet interface
produit: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
fabriquant: Realtek Semiconductor Co., Ltd.
identifiant matériel: 0.2
information bus: pci@0000:04:00.2
nom logique: eth0
version: 0a
numéro de série: 00:90:f5:fb:83:3e
taille: 1Gbit/s
capacité: 1Gbit/s
bits: 64 bits
horloge: 33MHz
Et la WOL ne fonctionne pas
La seule différence entre les deux machines la version du chipset network
PS: sur les deux machines Ubuntu 14.04 est installé avec le même noyau 3.13.0-83 generic
Merci pour toute piste ......
Hors ligne
Cette petite différence entre versions du contrôleur Ethernet se remarque aussi au niveau du firmware, avec la commande:
]sudo lshw
...
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8411-1_0.0.3 06/18/12 ip=192.168.1.39 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
Sur la W670SZQ1, on a:
sudo lshw
...
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8411-2_0.0.1 07/08/13 ip=192.168.1.39 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
Selon ce post sur unixblogger.wordpress.com, on résout de nombreux problème de connexion réseau en remplaçant le pilote r8169 inclus dans le noyau (voir ci-dessus) par le r8168 à télécharger sur http://www.realtek.com.tw/downloads/. Je viens de télécharger ce pilote, mais, avant de suivre la longue procédure d'installation, je me demande s'il est réaliste de demander à nos clients d'en faire de même en cas de problème. Et, s'il est installé dans notre build, est-ce que la prochaine mise à jour ne va pas réinstaller le pilote r8169?
Merci pour les conseils de spécialistes!
Hors ligne
Bon, en l'absence de conseils, je vais tenter ma chance et on verra...
Le paquet téléchargé sur http://www.realtek.com.tw/downloads/ se nomme 0004-r8168-8.041.01.tar.bz2 et se trouve dans Téléchargements.
Dans une fenêtre terminal ([Ctrl]+[Alt]+[T]), se donner les droits root et installer l'outil build-essential:
sudo su (suivi du mot de passe) apt-get install build-essential
Valider l'installation avec "O" ou simplement [Enter].
Ensuite, se déplacer dans Téléchargements et décompresser l'archive:
cd Téléchargements/ tar xfvj 0004-r8168-8.041.01.tar.bz2
Il faut ensuite blacklister l'ancien pilote dans /etc/modprobe.d/blacklist.conf:
gedit /etc/modprobe.d/blacklist.conf
J'ai rajouté à la fin du fichier:
# disable r8169 for Realtek RTL8111/8168/8411
blacklist r8169
avant de fermer et sauvegarder le fichier blacklist.conf.
Il faut ensuite se rendre dans le sous-répertoire r8168-8.041.01 créé précédemment dans Téléchargements pour créer et installer le pilote:
cd r8168-8.041.01/ make clean modules (attendre le retour du prompt .../Téléchargements/r8168-8.041.01#) make install
Il faut ensuite installer le nouveau driver dans le noyau:
depmod -a insmod ./src/r8168.ko
Reste à rendre le nouveau driver utilisable et disponible à chaque boot sur le noyau actuel (résultat de uname -r):
mkinitramfs -o /boot/initrd.img-`uname -r` `uname -r` echo “r8168” >> /etc/modules
Avant de redémarrer la machine, lspci -v nous indique (dernière ligne):
Kernel driver in use: r8169
et, en effet, après redémarrage:
Kernel driver in use: r8168
Reste à vérifier que le wake-on-LAN fonctionne maintenant...
Malheureusement, après avoir vérifié que le WOL était enclenché (Wake-on: g):
sudo ethtool eth0
et que l'adresse MAC de la machine à réveiller était bien la bonne (ici, eth0 HWaddr 00:90:f5:fb:83:3e):
ifconfig
l'autre machine sur laquelle j'avais installé l'utilitaire wakeonlan:
sudo apt-get install wakeonlan
la commande wakeonlan envoyait bien le paquet magique, mais sans réveiller la W650SZ:
wakeonlan 00:90:f5:fb:83:3e
Le problème est donc ailleurs! Toutes les idées sont les bienvenues...
Hors ligne
Il faudrait peut-être tester le petit script proposé à la fin de cette discussion sur ubuntuforums.org.
Ou encore le petit ajout dans init.d décrit dans cette autre discussion sur ubuntuforums.org.
Hors ligne
Bonjour,
Je viens de tester le petit script proposé à la fin de cette discussion sur ubuntuforums.org.
Créer un fichier pour le script:
gksu gedit /etc/pm/sleep.d/89_wol_reload_network_mod
et y coller le 2e script (celui qui utilise le driver r8169, car j'ai réinstaller le noyau d'origine):
#!/bin/sh case "$1" in hibernate|suspend) service network-manager stop modprobe -r r8169 ;; thaw|resume) modprobe r8169 service network-manager start ;; esac exit 0
avant de le rendre exécutable:
sudo chmod o+rwx /etc/pm/sleep.d/89_wol_reload_network_mod
Après un redémarrage, le script n'a rien amélioré. :-(
J'ai a tout hasard tenté le premier script proposé, mais en désignant le driver r8169:
#!/bin/sh case "$1" in thaw|resume) service network-manager stop modprobe -r r8169 modprobe r8169 service network-manager start ;; *) exit $NA ;; esac exit 0
Encore raté!
Hors ligne
Bon, le script était proposé à l'origine en complément avec le driver Realtech r8168. J'ai donc voulu tester la combinaison des deux et j'ai découvert qu'une nouvelle version du driver 0005-r8168-8.042.00.tar.bz2 était sortie aujourd'hui!... Un petit espoir...
Malheureusement, après redémarrage, rien n'a changé...
Et même en complément avec l'un ou l'autre des deux scripts proposés au post #10 pour le pilote r8168, suivi d'un redémarrage, le WOL ne se fait pas...
Hors ligne
Antoine Sibold a ouvert une discussion sur askubuntu.com et posé la question à Realtek au moyen du formulaire en ligne de support technique.
C'est un peu désespérant...
Hors ligne
Bonjour,
Personnellement, je ne vois pas le rapport entre le Wake on lan et la certification énérgy start 6
Êtes vous certains que les personne qui décide de ces normes connaissent le dossier et les conséquences entre autre sur la sécurité le logiciel et le matériel libre quand à l'étranger impossibilité d'obtenir ses labels Les failles de sécurité qu'ils mettent à cause d'exigence trop élevé ?
Salutations
Battant
Hors ligne
Bonjour Battant,
L'exigence est pourtant très claire dans la norme Energy Star 6.0 (Power Management Requirements, p. 12):
J'imagine que c'est pour permettre d'éteindre à distance toutes les machines inactives la nuit et le week-end, sans se priver de la possibilité d'installer des mises à niveau en dehors des heures de travail.
Cordialement.
Hors ligne
Je m'aperçois que je n'avais pas saisis un élément qui me semble plutôt important:
Je lis:
Computer swith ethernet capability shall provide users with an option to enable and disable WOL for Sleep Mode.
J'ai une machine qui éteinte répond aux magic packets et une qui en sleep répond au magic packets.
C'est pas tout à fait pareil.
Serait-ce une piste ?
Hors ligne
François Marthaler a écrit:
Bonjour Battant,
L'exigence est pourtant très claire dans la norme Energy Star 6.0 (Power Management Requirements, p. 12):
https://blog.whyopencomputing.ch/wp-con … ts_WOL.png
J'imagine que c'est pour permettre d'éteindre à distance toutes les machines inactives la nuit et le week-end, sans se priver de la possibilité d'installer des mises à niveau en dehors des heures de travail.
Cordialement.
Je m'excuse mais ça c'est pour les entreprises Pas pour les particuliers à qui ça peut poser des problèmes de sécurité et de vie privée.
Alors que faire pour respecter la vie privée des particuliers ?
Salutations
Battant
Hors ligne
Bonjour Battant,
C'est juste. Cela ne concerne que les entreprises. Mais, sachant qu'un ordinateur sur deux est un poste de travail professionnel, la norme en fait une exigence minimale...
:-((
Hors ligne
Bonsoir,
Bon d'accord alors faudrait-il deux version de la même norme une pour les particuliers et une pour les entreprises ?
Un Particulier souhaite-il vraiment être soumis aux mêmes exigences que les entreprises ? Personnellement je ne le souhaite pas
Avec mes meilleures salutations
Battant
Hors ligne
Pour ceux qui comprennent l'anglais, nous avons également posé la question sur ASK Ubuntu à l'adresse:
http://askubuntu.com/questions/770164/w … thernet-co
Malheureusement sans succès pour le moment.
Cette question est cruciale pour nous.
Merci d'avance pour toute aide!
Hors ligne