Bonjour à tous,

ceci étant mon premier post ici, je me présente rapidement: je suis Arnaud, j'ai tâté Linux il y a maintenant 10ans, j'utilise / utilisais Ubuntu 10.04 depuis 5 ans et j'ai été pendant environ 1 an (!!) à la recherche de ce par quoi je pourrais le remplacer car il vieillit.
Après avoir installé quasiment tout ce qui est dispo avec un noyau 3XX et avoir été très déçu car beaucoup de choses ne marchent plus ou beaucoup moins bien, que mon Ubuntu10.04, je suis arrivé à Fedora21 suite aux conseils d'un ami.
Et bien je pense avoir trouvé le successeur d'Ubuntu chez moi car je suis agréablement surpris que cet OS soit "à jour" et....... fonctionne très bien, quasiment du premier coup.

C'est justement le wake on lan qui me fait écrire "quasiment":
- sur ma machine F21-gnome3 le WOL ne fonctionne pas (mais fonctionne quand la machine est éteinte depuis Ubuntu, qui est encore en dual-boot)
- sur ma machine F21-mate, le WOL fonctionne parfaitement.

J'ai fait la même chose sur les 2 machines:
- dans /etc/sysconfig/network-scripts/ifcfg-macarte : j'ai ajouté 
ETHTOOL_OPTS="wol g"
- dans /etc/rc.d/rc.local j'ai ajouté: 
/usr/sbin/ethtool -s <tacarte> wol g
Sur la machine rétissante ethtool indique pourtant automatiquement: 
[arnaud@fedora21-KCN ~]$ sudo ethtool enp1s0
Settings for enp1s0:
	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/Half 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/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
Donc avec "Wake-on: g" ça devrait aller, mais.......ça ne va pas encore! 🙁

J'ai donc cherché un peu plus loin et j'ai trouvé 2 pistes que je n'arrive malheureusement pas à exploiter:
- /proc/acpi/wakeup . Dedans, je devrais d'après ce que j'ai lu, voir si mon interface (dont "lspci" me donne le numéro) est "disabled" ou "enabled". Malheureusement, le numéro de mon interface n'apparait pas dans ce fichier. Pourquoi?? Pour plus de précisions, je peux poster lspci et le contenu du fichier wakeup.

- /etc/sysconfig/network-scripts: là il y aurait éventuellement des modifs à faire dans "ifup"? "ifdown"? et quelles modifs??

Je le répète. cette machine démarre si elle a été éteinte depuis Ubuntu --> le hardware est OK, le bios aussi.

Merci par avance pour vos indications.

@+
Arnaud
Bonsoir,

et merci pour vos remarques. 🙂
le service rc-local est-il démarré ? 
[arnaud@fedora21-KCN ~]$ ls -l /etc/rc.d/rc.local 
-rwxr-xr-x 1 root root 93  3 mars  17:14 /etc/rc.d/rc.local
--> c'est bien le "bon" fichier, dans le "bon" répertoire avec les "bonnes" permissions? 
[arnaud@fedora21-KCN ~]$ cat /etc/rc.d/rc.local 
#!/bin/bash

#/usr/sbin/fancontrol &>/dev/null & 

/usr/sbin/ethtool -s enp1s0 wol g

exit 0
--> c'est bien la bonne commande? (j'ai commenté la ligne de fancontrol pour les essais afin d'éviter tout interaction négative.....). Je n'ai qu'une interface réseau et "ifconfig" m'indique que c'est "enp1s0" avec un "zéro" et non un O majuscule.
[arnaud@fedora21-KCN ~]$ systemctl status rc-local.service
● rc-local.service - /etc/rc.d/rc.local Compatibility
   Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
   Active: active (exited) since mar. 2015-03-03 16:17:01 CET; 2h 25min ago
--> le retour est bien correct?

Ai-je quelque part une erreur de frappe????


Ce topic http://forums.fedora-fr.org/viewtopic.php?id=28038 a attiré mon attention.
Je suis étonné dans mon cas du retour de : 
[arnaud@fedora21-KCN ~]$ chkconfig

Avertissement : cette sortie n'affiche que les services SysV et n'inclut pas les services
                natifs systemd. Les données de configuration de SysV peuvent être surchargées par la configuration
                native de systemd.

      Si vous désirez lister les services systemd, utiliser 'systemctl list-unit-files'.
      Pour voir les services activés par une cible particulière, utiliser
      'systemctl list-dependencies [target]'.

jexec          	0:arrêt	1:marche	2:marche	3:marche	4:marche5:marche	6:arrêt
livesys        	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche6:arrêt
livesys-late   	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche6:arrêt
netconsole     	0:arrêt	1:arrêt	2:arrêt	3:arrêt	4:arrêt	5:arrêt	6:arrêt
network        	0:arrêt	1:arrêt	2:arrêt	3:arrêt	4:arrêt	5:arrêt	6:arrêt
Apparemment c'est normal que "netconsole" et "network" soient tout le temps à l'arrêt, car c'est également le cas sur la bécane où le WOL fonctionne. J'aurais pourtant cru qu'au moins en état 5 il y aurait "marche" car j'ai bien du réseau quand la machine est démarrée.
--> comment voire les différents état de mon interface réseau?

Apparemment ce topic http://forums.fedora-fr.org/viewtopic.php?id=37790 va dans la même direction.


@+
Arnaud
Vu ton ethtool le wake on lan est bien à g donc pas la peine de passer plus de temps dessus. Est-ce que t'as bien 
cat /sys/class/net/enp1s0/device/power/wakeup
qui t'indique enabled?

Le wake on lan a t'il déjà fonctionné sur cette machine?
Bonsoir et merci de te pencher sur mes difficultés
madko wrote:Vu ton ethtool le wake on lan est bien à g donc pas la peine de passer plus de temps dessus.
Ça me rassure, car c'était bien ce que j'avais déduit.
madko wrote:Est-ce que t'as bien 
cat /sys/class/net/enp1s0/device/power/wakeup
qui t'indique enabled? 
[arnaud@fedora21-KCN ~]$ cat /sys/class/net/enp1s0/device/power/wakeup
enabled
--> c'est ok.
madko wrote:Le wake on lan a t'il déjà fonctionné sur cette machine?
Oui, il fonctionne même tous les jours, mais pour ça il faut que je reboote sur Ubunu 10.04 (en dualboot), pour de là arrêter la machine "correctement" --> AMHA ça ne peut être un problème de hardware ou de bios.

@+
Arnaud
Oui effectivement si ça marche après un arrêt sous Ubuntu on peut dire que c'est pas un soucis matériel et/ou bios. C'est déjà ça en moins.

Ce qui est dingue c'est que ça fonctionne aussi sous F21 Mate? T'es en wol g aussi? y compris sur Ubuntu?

Faudrait comparer les versions de kernel, si c'est bien les mêmes. Idem pour les options du pilote (tu peux avoir le nom de ce dernier avec lspci -k).
J'avoue ne pas comprendre....

A partir d'une Fedora 21 je démarre sans problème un vieux Dell OptiFlex GX520 sur lequel il y a une vieille Fedora 18 en utilisant ether-wake pour envoyer un magic packet à la MAC address de ce Dell...

J'ai juste indiqué au niveau du BIOS de ce Dell que je voulais que celui-ci accepte le Wake-on-LAN... RIen de plus et aucun paramétrage au niveau de la Fedora...

Et je peux éteindre ce Dell avec la commende shutdown en SSH, il redémarre sans problème derrière...

Après il faudrait préciser ce que tu entends par "ne fonctionne pas":
arnaud056 wrote:C'est justement le wake on lan qui me fait écrire "quasiment":
- sur ma machine F21-gnome3 le WOL ne fonctionne pas (mais fonctionne quand la machine est éteinte depuis Ubuntu, qui est encore en dual-boot)
- sur ma machine F21-mate, le WOL fonctionne parfaitement.
La machine se réveille ?
Le boot commence ?
Bonsoir et merci pour le retour 😉
madko wrote:Ce qui est dingue c'est que ça fonctionne aussi sous F21 Mate? T'es en wol g aussi? y compris sur Ubuntu?
Ça n'est pas tout à fait exact:
- le WOL ne fonctionne pas sur la machine 1, avec F21_gnome3 ainsi qu'avec F21_mate. Par contre ça fonctionne lorsque cette machine est arrêtée par Ubuntu.
- sur la machine 2, avec F21_mate, le WOL fonctionne depuis que j'ai appliqué la procédure "normale" (cf post1)

madko wrote:Faudrait comparer les versions de kernel, si c'est bien les mêmes. Idem pour les options du pilote (tu peux avoir le nom de ce dernier avec lspci -k).
Afin de ne pas rendre le topic illisible, je ne poste que la partie consacrée à l'interface réseau. Si besoin, je peux en mettre plus:

Machine 1 - F21 gnome et mate - pas de WOL 
[arnaud@fedora21-KCN ~]$ lspci -k
...................

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
	Subsystem: ASRock Incorporation Motherboard (one of many)
	Kernel driver in use: r8169
	Kernel modules: r8169
.........

03:06.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)
	Subsystem: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card
	Kernel driver in use: b2c2_flexcop_pci
	Kernel modules: b2c2_flexcop_pci

[arnaud@fedora21-KCN ~]$ uname -r
3.18.7-200.fc21.x86_64
Machine 1 - Ubuntu 10.04 - WOL OK 
arnaud@kcnathlon:~$ lspci -k
.................
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
	Kernel driver in use: r8169
	Kernel modules: r8169
..............
03:06.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)
	Kernel driver in use: b2c2_flexcop_pci
	Kernel modules: b2c2-flexcop-pci
arnaud@kcnathlon:~$ uname -r
2.6.32-73-generic
--> C'est bien le même pilote: r8169 qui est utilisé.
Vous aurez noté que j'ai une carte satellite qui est, à mon grand étonnement, nommée "Network controller".....

Machine 2 - F21 mate - WOL OK 
[arnaud@fedora-asrock ~]$  lspci -k
...................
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
	Subsystem: ASRock Incorporation Motherboard (one of many)
	Kernel driver in use: r8169
	Kernel modules: r8169
04:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter
	Kernel driver in use: 8139too
	Kernel modules: 8139cp, 8139too
...............
[arnaud@fedora-asrock ~]$ uname -r
3.18.7-200.fc21.x86_64
--> Ici la machine possède 2 inferfaces réseau. Seule celle Onboard est physiquement branchée --> c'est la 1ère des 2, également avec le pilote r8169.
madko wrote: F21 Mate? T'es en wol g aussi? y compris sur Ubuntu?
Oui, sur la machine où le WOL fonctionne avec F21Mate j'ai bien wol g en retour d'ethtool.
Sur la machine qui pose problème avec F21 mais oú c'est OK sous Ubuntu, j'ai bien également sous Ubuntu 
arnaud@kcnathlon:~$ sudo ethtool eth0  | egrep "^[[:blank:]]*Wake-on: (g|d)"
[sudo] password for arnaud: 
	Wake-on: g
didierg wrote:il faudrait préciser ce que tu entends par "ne fonctionne pas":
Quand la machine est arrêtée depuis F21 (= arrêt "normal" par gnome ou mate en graphique ou "shutdown -h now" en console), elle ne réagit pas à la réception d'un paquet magique. Il ne se passe absolument rien. Pas de réveil. Donc pas de boot.

Manque-t'il encore des infos pour cerner le problème?

@+ et encore merci pour le soutien.
Arnaud
Salut Arnaud, salut à tous,

Comme Arnaud, je découvre Fedora (c'est d'ailleurs lui qui m'y a encouragé ) et j'ai un peu d'expérience sous Linux. Nous avons un peu discuté de son problème par mail avant qu'il poste ici et du coup j'ai pris un moment pour regarder comment se comporte le Wake On Lan et si je pouvais trouver une piste pour l'aider.

Mais du coup, je suis assez sceptique, ayant moi aussi des résultats différents sur deux machines différentes ! Je fais un petit REX, tant pour essayer de faire avancer le schmilblic que pour tenter d'avoir quelques explications.

J'ai installé F21 sur :
  1. Une machine équipée d'une carte mère MSI G41-P33-Combo (ethernet Realtek RTL8105EL),
  2. Une machine équipée d'une carte mère Gigabyte GA-G31M-ES2L (ethernet Realtek RTL8111C)
Les deux on quasiment la même configuration logicielle, et étaient à jour au moment des essais.

sur la machine MSI G41-P33-Combo, le WOL a fonctionné immédiatement, alors que sur la GA-G31M-ES2L, il a fallu que j'ajoute la ligne 
ETHTOOL_OPTS="wol g"
dans /etc/sysconfig/network-scripts/ifcfg-enp2s0 et que je crée et active le fichier rc.local, que je croyais être une roue de secours mais qui s'avère indispensable. Je n'ai pas fait l'essai, mais Arnaud me disait ce soir qu'il a constaté de son côté, sur sa machine où le WOL fonctionne, que l'ajout dans ifcfg-machin ne sert à rien, le WOL fonctionne aussi bien sans !

Donc :
  • Je peux confirmer que le WOL fonctionne bien sur mes deux machines
  • Je serais quand même bien curieux d'avoir quelques explications sur 3 points :
    1. Pourquoi faut-il "bricoler" une machine alors que l'autre fonctionne "out of the box" ?
    2. Que se passe-t-il sur celle d'Arnaud où on ne peut pas incriminer le matériel, puisque le WOL fonctionne très bien après utilisation d'Ubuntu (multiboot Ubuntu, F21-gnome3 et F21-mate) et que par ailleurs la même config sur une autre machine fonctionne parfaitement ?
    3. Passons sur le nom lui-même de l'interface (eth0 est quand même bien plus habituel !), mais pourquoi enp2s0 alors que la seule et unique carte est onboard, quand mon autre machine et au moins une de celle d'Arnaud est nommée enp1s0 ? Ce qui provoque cette différence de nommage pourrait-il mettre sur une piste en ce qui concerne les comportements différents d'un matériel à l'autre ?
PS : Certains semblant un peu s'y perdre, je re-précise le problème d'Arnaud : Le Wake on Lan fonctionne bien sur une machine sous Fedora-mate, mais pas sur une machine sur laquelle il a un multiboot entre Ubuntu, Fedora-gnome3 et Fedora-mate, alors que sur cette même machine le WOL fonctionne s'il a utilisé Ubuntu. Autrement dit, sur cette machine, les deux versions de Fedora ne préparent pas la carte pour le WOL, alors qu'Ubuntu la prépare bien.
Comme sur un autre sujet il y a peut, il est fort possible que les noms ne soient pas les mêmes, d'où l'amalgame fort possible.

Les interfaces graphique ayant la fâcheuse tendance à changer les noms.
Salut,

Merci pour cette réponse intéressante et surprenante, qui aurait cependant mérité un peu plus de précisions. Je ne pensais pas que cette différence de nommage venait des interfaces graphiques, mais après tout c'est bien possible. Resterait, au moins par curiosité, à savoir le pourquoi et le comment de ces changements de noms qui, si je comprends bien, n'auraient pas eu lieu si tout passait par la bonne vieille ligne de commande.

Mais surtout ça m'inquiète, parce que si les interfaces graphiques décident de leur propre chef de changer les noms des interfaces, rien n'empêche qu'elles changent d'autres choses à notre insu et par exemple, pourquoi pas, la manière de réagir à un WOL ou encore celle de traiter la prise en compte de la ligne «ETHTOOL_OPTS="wol g"» dans ifcfg-truc...

C'est vrai que dans ce cas, on devrait bien en retrouver trace quelque part, comme on constate les différences de nom. Mais faute de comprendre ces différences de comportement assez mystérieuses, il faut bien envisager toutes les possibilités et tout étudier attentivement !

Concernant le sujet traité il y a peu dont tu parles, peux-tu nous mettre un lien dessus STP ? Je ne sais pas trop sur quels mots clés lancer une recherche pour le trouver... (si tu n'as pas le temps de le rechercher, au moins quelques pistes pour qu'on puisse le faire nous-mêmes). [EDIT] Ooops, s'agirait-il de ce post ? Désolé, je n'avais pas vu le second sujet d'Arnaud, il ne m'a pas dit qu'il avait posté aussi cette question. [/EDIT]

[EDIT2]Bon, je crois que ce post est finalement sans objet, le sujet a été abordé dans ce fil (contenant le post sus-mentionné) et les meilleures réponses se trouvent probablement dans ce document que je vais m'empresser de lire. Merci quand même, au moins d'avoir pris le temps de me lire ![/EDIT]
non les changements de nom n'ont à l'origine aucun rapport avec les interfaces graphiques. Ces changements sont fait pour regler le problème d'ordre d'apparition des cartes réseaux, et vient donc plutôt d'un problème industriel à la base (c'est encore rare et peu utile d'avoir plusieurs cartes réseaux dans nos PC).

A l'origine le problème est simple:
- udev et le kernel chargent les pilotes et leur nom en parallèle, aucun ordre, donc rester sur eth0, eth1 etc n'est pas pratique. Un coup on démarre on a un ordre, au prochain reboot on en a un nouveau... Recabler un serveur après chaque reboot (bon la propension n'était pas si systématique) c'était pas viable. Avant le kernel linux chargeait tout ça en série donc le soucis était moins présent. C'est ce que font encore certains OS, et qui en plus utilisent le nom du driver dans le nom de la carte réseau (c'est pas mal aussi comme solution). Mais comme on veut des OS qui bootent de plus en plus vite, il faut paralleliser.

Dell a été un des premiers à tenter de résoudre le problème. Ils ont ajouté une entrée personnalisable dans le BIOS pour chaque interface.

La communauté linux y a répondu en ajoutant ce support, grâce au travail de Dell en partie (scripts biosdevname etc). Maintenant les noms sont basés principalement sur l'emplacement physique de la carte reseau (p0s0 port 0 slot 0 etc). Bien sûr libre à vous de renommer comme vous le souhaitez. L'interface graphique s'appuie la dessus pour proposer plus de liberté.

désolé pour cet hors sujet.
Cela peut donner un nom différent de ce qui est en place parfois, j'ai eu le cas il y a peut avec un ifcfg-xxxmachin1 alors que c'est ifcfg-enp3s0, donc pour résultat un beau bordel. Bon après c'était à une époque, maintenant il prend ce qu'il trouve sans ajouter/modifier quelque chose. Du coup que des soucis pour la prise en compte de la configuration... Bon après on peut faire des liens avec des noms différents.

Donc si l'on modifie le fichier ifcfg-nom ,alors que c'est enp...s... qui doit être modifié, il arrive que ce que l'on modifie ne fonctionne pas.
madko wrote:désolé pour cet hors sujet.
Merci pour ces explications qui répondent très bien à ma question et à mes inquiétudes. Si ce n'est pas vraiment en rapport avec les problèmes de WOL, je pense qu'Arnaud sera malgré tout heureux de mieux comprendre comment cela fonctionne, et ça nous évite de nous fourvoyer sur une piste que nous étions un peu tentés de suivre.

C'est en éliminant les fausses pistes qu'on finit par trouver la bonne, et la preuve ou l'explication qu'une piste est fausse n'est donc pas du tout hors sujet ! 🙂
VINDICATORs wrote:Cela peut donner un nom différent de ce qui est en place parfois, j'ai eu le cas il y a peut avec un ifcfg-xxxmachin1 alors que c'est ifcfg-enp3s0, donc pour résultat un beau bordel. Bon après c'était à une époque, maintenant il prend ce qu'il trouve sans ajouter/modifier quelque chose. Du coup que des soucis pour la prise en compte de la configuration... Bon après on peut faire des liens avec des noms différents.

Donc si l'on modifie le fichier ifcfg-nom ,alors que c'est enp...s... qui doit être modifié, il arrive que ce que l'on modifie ne fonctionne pas.
Bon, donc il y a la théorie (donnée par madko) et la pratique (que tu donnes) ! Faire attention donc de bien s'assurer de modifier le bon fichier de config ! Mais hormis ce problème de nom de fichiers de config, pourrait-il y avoir d'autres changements qui permettraient d'expliquer les problèmes de fonctionnement du WOL dont se plaint Arnaud et les comportements différents d'une machine à l'autre que j'ai constatés ?
Pour le fichier ifcfg le nom dans ifcfg-nom n'est pas vraiment utile. Il prête à confusion ce qui est pire. En réalité ce qui est important c'est le contenu du fichier. A l'intérieur il y a NAME et DEVICE voire UUID et même HWADDR, qui permettent de clairement cibler l'interface concernée. (lire le script ifup, même s'il a l'air d'avoir été écrit par un stagiaire, c'est intéressant).

Quand je parlais des changements de nom je parlais des noms des interfaces. Peut être qu'on parlait pas de la même chose. Le nom de ifcfg-nom là il peut changer comme on veut, et certains outils s'en privent pas. Du moment comme dit juste avant que ça pointe ensuite sur la bonne carte (via NAME/DEVICE/UUID).

Pour le problème de WOL ça ressemble à un problème de driver/kernel vu que sur la machine 1 c'est OK avec Ubuntu qui a des drivers et un kernel plus ancien. En tout cas la conf ethtool est correcte.

Donc le soucis est sur:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
+
kernel 3.18.7-200.fc21.x86_64

Si j'ai bien suivi?

Sur la machine 2 où le WOL fonctionne la carte n'est pas exactement la même:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
@arnaud : je t'avais bien dit d'essayer avec une autre carte 😉

@madko : Bien vu ! Je n'avais pas fait attention à la rev différente, je pensais plus à un dysfonctionnement anormal qu'à un problème de conception ou d'adéquation avec le driver. Un problème de carte, alors, parce que je suis surpris que le driver traite bien la rev03 alors qu'il ne traite pas bien la rev01 logiquement plus ancienne et bien traitée par Ubuntu ?

La différence de cartes pourrait-elle expliquer-t-elle aussi que chez moi sur une machine le WOL fonctionne sans aucune config préalable et sur l'autre ne fonctionne qu'avec la mise en place de rc.local, l'ajout de la ligne ETHTOOL... dans ifcfg-machin étant inefficace ? (Realtek RTL8105EL et Realtek RTL8111C, je donnerai les caractéristiques précises si besoin, mais reboot, sortie dans un fichier sur une clé USB etc. etc... je suis un peu flemmard si ce n'est pas vraiment utile !)
+1 madko, mais faut quand même faire attention, car les interfaces ne sont pas toujours fiable à 100%. La confusion venant aussi selon les habitudes que l'on prend ici et là.

Si c'est une régression, il faut, je pense, la rapporter, voir si il n'y a pas eu une modif faite propre à ubuntu (les noyau ne sont pas toujours à 100% identique). Dans tout les cas la rapporter quand même sur le bugzilla ne serait pas un mal.
Re-bonjour, 🙂
madko wrote:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
+
kernel 3.18.7-200.fc21.x86_64

Si j'ai bien suivi?

Sur la machine 2 où le WOL fonctionne la carte n'est pas exactement la même:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
Moi non plus je n'avais pas vu ça! Merci bien pour ton attention!
Cela prouve encore une fois que celui qui lit tout a l'avantage.......

Bon, et bien le problème semble cerné --> je vais pouvoir faire une recherche avec cette combinaison pour voir si c'est connu et surtout si ça a été déjà résolu.
jibe74 wrote:@arnaud : je t'avais bien dit d'essayer avec une autre carte wink
c'est pas si simple car...... elle est on-board! 🙁
Je vais cependant voir si j'ai encore de la place pour en mettre une supplémentaire en PCI.

Je vous tiens au courant de la suite des évènements et encore merci pour vos indications respectives.

@+
Arnaud