je n’en sais pas plus non plus, je n’utilise jamais cette fonctionnalité, et les endroits où je travaille ou ai travaillé ne l’utilise pas non plus, le plus souvent pour des raisons de sécurité.
etherwake n’envoie pas des paquets IP, donc encore moins UDP. Apparemment ils ont l’ethertype 0x0842.
En revanche le script wakeonlan du paquet éponyme envoie des paquets UDP.
Qu’est-ce que cette doc entend par « activer le broadcast UDP » ?
Je connais le broadcast ethernet et le broadcast IP, mais pas le broadcast UDP.
C’est du broadcast IP en fait. Broadcast UDP comme pour TCp c’est un abus de langage en fait.
Soit, mais ça ne m’explique toujours pas ce que signifie « activer le broadcast IP ».
Ben, je ne sais pas trop, on peut imaginer que ce serait ne router que les paquets UDP mais c’est se tromper de couche puisqu’à mon mon sens le broadcast est au niveau IP au plus haut. Mais je me trompe peut être ou, plus probable, je n’ai pas compris la doc (lecture en diagonale en plus).
Ah ben voilà, je les pensais identiques. Donc après enregistrement du trafic et analyse par wireshark, effectivement il y a une différence entre les 2, wakeonlan encapsule le magic packet dans un paquet UDP (on y retrouve les 6 0xff suivi de l’adresse MAC et l’entête du paque WOL). etherwake envoie un paquet WOL seul. Les paquets UDP ne sont pas repercutés sur tous les ports du VLAN, en revanche les paquets WOL si (donc Pascal, tu as raison comme toujours sur les histoires de réseaux 
), et wakeonlan envoie par défaut ses paquets UDP sur une adresse broadcast (mais on peut les envoyer à une adresse IP précise (si on a un routage ad hoc je présume)).
Pour voir passer les paquets WOL, on a par tcpdump pour un tel paquet
11:34:21.150174 00:e0:7d:e2:51:ed (oui Unknown) > c8:9c:dc:d6:68:f4 (oui Unknown), ethertype Unknown (0x0842), length 116:
donc pour les capturer eux seulement
tcpdump -i eth0 ether proto 0x0842
(et non
tcpdump -i eth0 proto 0x0842
comme je l’ai bêtement fait).
En principe, il ne devrait pas y avoir de différence entre les paquets UDP et les paquets WOL « purs » d’etherwake (ou tout autre type de paquet), la diffusion devrait dépendre uniquement de l’adresse ethernet de destination du paquet :
- si le paquet est adressé à l’adresse de broadcast (ff:ff:ff:ff:ff:ff), il devrait être diffusé sur tous les ports du VLAN
- si le paquet est adressé à une adresse unicast inconnue de la table MAC du switch, il devrait etre diffusé sur tous les ports du VLAN
- si le paquet est adressé à une adresse unicast connue de la table MAC du switch, il devrait être retransmis uniquement sur le port correspondant
(Je ne traite pas le cas des adresses multicast, ça dépend trop du switch et de sa configuration.)
Oui, l’encapsulation dans IP est utile pour réveiller une machine située dans un autre réseau via l’adresse IP de broadcast dirigé, le broadcast ethernet n’étant pas routable.
Ça on est bien d’accord, bienvenue dans ma vie de tech…
Mon chef vient de me répondre qu’il ne connaît pas l’adresse de broadcast du Vlan p, donc pour tester le paquet wakeonlan (que je ne connaissais pas, j’avais juste vu le paquet etherwake dans le tuto) ça va être compliqué.
J’ai tenté etherwake -i IpMachine MacMachine mais ça ne marche pas.
Bonjour
Est-ce qu’il est possible de connaître les références du switch concerné ?
Si je vais sur place je peux essayer de voir, oui.
Quel serait l’impact du modèle de switch sur le problème ?
Pour savoir :
- comment il est configuré par défaut,
- quels sont ses possibilités de configuration
- utiliser ses référence pour faire des recherches associées au mot
wolou/etwakeonlan - etc.
C’est quand même par lui que tout, rien, un peu devrait pouvoir passer.
Si la machine émettrice est dans le VLAN cible, pas besoin de connaître de l’adresse IP de broadcast dirigé, on peut utiliser l’adresse IP de broadcast limité 255.255.255.255. Par contre je ne sais pas comment fait wakeonlan pour déterminer l’interface de sortie dans ce cas, surtout si c’est une interface VLAN taggée. Au pire tu peux affecter une configuration IP bidon à l’interface VLAN et utiliser wakeonlan avec l’adresse de broadcast dirigé correspondante, ça devrait suffire à envoyer le paquet WOL. Mais je ne vois pas ce que ça apporte par rapport à etherwake.
« Ça ne marche pas » n’aide pas beaucoup. La commande se termine sans erreur ? Le paquet est émis sur le VLAN ?
D’après la page de manuel, l’option -i attend le nom d’une interface, pas une adresse IP.
Mes excuses, je voulais dire « wakeonlan -i IpMachine MacMachine ».
Cette commande ne donne aucune information autre que « Sending magic packet to IpMachine:9 with MacMachine ».
Je n’ai pas pensé à faire la commande en mode verbose, mais avec etherwake le mode verbose n’aidait pas beaucoup.
Je ne peux plus tester pour l’instant, j’ai éteint le raspberry pour qu’on me le rapporte au bureau pour pouvoir tester dans des conditions contrôlées (notamment avec un switch à la configuration duquel j’ai accès).
La suite au prochain numéro donc…
Sans doute une bonne idée de pouvoir te remonter un lab pour vérifier le comportement déjà.
Bon ben sur la configuration testée au bureau (switch avec deux ports configurés pour être sur le VLAN 1) la commande etherwake -i eth0.p MACAddressDeLaBécane réveille bien la bécane en question.
Donc comme je n’ai pas accès à la configuration d’aucun des deux switchs, j’abandonne et je considère que j’ai fait ma part du boulot.
Avec le port côté source taggé et le port côté cible non taggé pour coller à la configuration de prod ?
De ce qu’on m’a dit, oui.
Et comme on ne m’a donné accès à la configuration d’aucun des deux switchs pour vérifier moi-même, j’abandonne.