Aller au contenu

Messages recommandés

Posté(e)

Bonjour,

J'ai besoin de réveiller périodiquement et automatiquement un PC sur mon réseau local, et du coup je cherche comment émettre un wake-on-lan depuis mon NAS (DS218j), puisqu'il est toujours allumé. Sous Linux je sais qu'il existe la commande `wakeonlan`, mais elle n'est visiblement pas disponible sur le Syno. Existe-t-il une autre commande (vu que DSM est basé sur BSD et pas sur Linux le nom de la commande est peut-être différent), ou bien y a-t-il moyen de l'installer ?

Merci

 

Posté(e)

Merci... mais je ne sais pas pourquoi, ça ne marche pas...

Le PC se réveille bien quand j'utilise une appli de WoL installée sur mon téléphone. Il est par ailleurs bien sur le même sous-réseau que le NAS. Mais la commande ne fait rien... J'ai bien vérifié que j'entrais la bonne adresse MAC. Sur l'appli du téléphone j'ai spécifié le port 9, qui est normalement le port par défaut du WoL, mais est-ce que cette commande envoie bien sur le port 9 ?

 

Posté(e)

POur l'instant j'ai juste essayé de lancer la commande dans un terminal, avec un sudo

sudo synonet --wake <adresse_MAC> eth0

La commande s'exécute correctement, mais sans résultat

Posté(e) (modifié)

Confronté au même besoin, je ne suis également pas parvenu à avoir de succès avec la commande "synonet" (que pourtant il me semblait me souvenir avoir utilisé dans le passé)
Je n'ai pas trouvé plus simple que d'installer ce module Python : https://github.com/remcohaszing/pywakeonlan (dans un virtualenv pour faire plus propre)

Et je confirme que ça fonctionne (je réveille mon PC une fois par semaine pour que sa sauvegarde planifiée s'exécute)

Modifié par CoolRaoul
Posté(e)

Bonjour,

Perso j'utilise aussi la commande synonet --wake 14:xx:xx:xx:xx:c1 eth0 sur un DS220 avec l'utilisateur root et ça marche sans problème (sans sudo au début).

Posté(e)
j'utilise aussi la commande synonet --wake 14:xx:xx:xx:xx:c1 eth0 sur un DS220 avec l'utilisateur root et ça marche sans problème (sans sudo au début).
Je ne pense pas que [mention=76055]PierU[/mention] trouve utile de savoir que la méthode qu'il essaie sans succès d'utiliser marche chez d'autres.
De mon côté j'ai également retesté "synonet" en ligne de commande, autant avec sudo à partir d'un compte non root que sans dans un shell "full root" ("sudo -i") et ça n'a marché dans aucun des cas.

Posté(e)

@PierU Il pourrait être intéressant que tu installes Wireshark sur ton PC et que tu compares le magic packet que tu reçois lors de l'utilisation de synonet et celui reçu lors de l'utilisation du logiciel.

Posté(e) (modifié)
Il y a 2 heures, .Shad. a dit :

@PierU Il pourrait être intéressant que tu installes Wireshark sur ton PC et que tu compares le magic packet que tu reçois lors de l'utilisation de synonet et celui reçu lors de l'utilisation du logiciel.

Voulant en avoir le cœur net j'ai testé avec Wireshark.

Avec le module Python je capture bien le "magic packet": 

image.png.a14874cfe4b1dd7bf8013737ae1463b1.png
Avec "synonet --wake" : rien

J'ai meme essayé un tcpdump en ligne de commande sur une autre fenêtre shell directement sur le NAS ("sudo tcpdump -i eth0 '(udp and port 7) or (udp and port 9)'") ; pas mieux

 

 

 

Modifié par CoolRaoul
Posté(e)
Et en utilisant le chemin absolu au lieu du relatif : /usr/syno/sbin/synonet ?
Je ne suis plus chez moi la et donc plus d'accès à mon PC et à son Wireshark
Mais je ne vois pas quelle différence ça pourrait faire 5cbcd1c5e92b00cb6e5a1cbb365446bf.jpg


Posté(e) (modifié)
il y a 50 minutes, .Shad. a dit :

Et en utilisant le chemin absolu au lieu du relatif : /usr/syno/sbin/synonet ?

Effectivement, il semble que chez certains la commande suivante ne fonctionne pas:

--wake XX:XX:XX:XX:XX:XX eth0

alors que celle-ci fonctionne: 

/usr/syno/sbin/synonet --wake XX:XX:XX:XX:XX:XX eth0
Modifié par cadkey
Posté(e) (modifié)

Par acquis de conscience j'ai testé avec le chemin complet : tout autant sans résultat.

Quand on fait une recherche "synonet wake" sur Google, on trouve quand même pas mal de résultats où des utilisateurs disent aussi que ça ne marche pas (mais chez d'autres ça marche, en effet).

 

Modifié par PierU
Posté(e) (modifié)
Il y a 14 heures, cadkey a dit :

il semble que chez certains la commande suivante ne fonctionne pas

<HS>

le fait qu'une *même* commande se comporte différemment selon qu'on utilise un chemin absolu ou la résolution via le PATH (étant donné que l'identité du chemin de la cible est confirmé par un "which <commande>" ) remet en cause toute mon expérience du fonctionnement des shells Unix.
Un pointeur vers un cas avéré m'intéresse au plus haut point

</HS>

Modifié par CoolRaoul
Posté(e)

Clairement il y avait peu de chance que ça donne quelque chose je suis d'accord avec toi, mais j'ai trouvé plusieurs retours en ce sens sur les forums officiels Synology, ça ne coûtait pas grand chose de tester.

Posté(e)
Il y a 22 heures, CoolRaoul a dit :

Je ne pense pas que [mention=76055]PierU[/mention] trouve utile de savoir que la méthode qu'il essaie sans succès d'utiliser marche chez d'autres.

 

OK, désolé d'avoir précisé que ça marchait chez d'autres...

Posté(e) (modifié)

J'ai testé sur 3 NAS différents (DSM 6 et 7), aucun d'entre eux n'émet de paquet WoL avec la commande :

sudo synonet --wake xx:xx:xx:xx:xx:xx ethX

Pour voir les paquets WoL émis par le NAS, ouvrez une 2ème session SSH et exécutez :

sudo tcpdump -Anqi any 'udp port (0 or 7 or 9)'

Ça affichera n'importe quel paquet WoL entrant ou sortant (udp/9 est le plus utilisé, mais on trouve parfois udp/0 ou udp/7).

Modifié par PiwiLAbruti
Correction suggérée par @CoolRaoul
Posté(e) (modifié)
Il y a 1 heure, aj13fr a dit :

OK, désolé d'avoir précisé que ça marchait chez d'autres...

Je suis vraiment désolé que ça soit tombé sur toi, mais je ne compte plus le nombre de fois où je tombe sur une réponse "chez moi ça marche" dans un fil ou un utilisateur vient demander de l'aide. Et parfois je réponds avec ce genre de remarque qui, je le reconnais, peut s'avérer désagréable.

il y a une heure, PiwiLAbruti a dit :
sudo tcpdump -Anqi ethX 'udp port (0 or 7 or 9)'

mieux alors: 
sudo tcpdump -Anq -i any 'udp port (0 or 7 or 9)'

(au cas ou le nom des interface LAN est différent selon le modèle de NAS)

 

Modifié par CoolRaoul
Posté(e)
Il y a 2 heures, CoolRaoul a dit :

Je suis vraiment désolé que ça soit tombé sur toi, mais je ne compte plus le nombre de fois où je tombe sur une réponse "chez moi ça marche" dans un fil ou un utilisateur vient demander de l'aide. Et parfois je réponds avec ce genre de remarque qui, je le reconnais, peut s'avérer désagréable.

Pas de souci 😉

 

@+

Posté(e)

Oui, l'option est bien visible dans l'aide de la commande. Pourtant elle ne fonctionne sur aucun NAS que j'utilise, aussi bien sous DSM 6 que 7.

Pour ceux chez qui ça marche, vous pouvez faire une capture du paquet envoyé par le NAS ? (avec la commande tcpdump donnée un peu plus haut)

Vous pouvez utiliser la commande suivante pour générer un fichier lisible par WireShark :

sudo tcpdump -s 0 -i any 'udp port (0 or 7 or 9)' -w wol.pcap

 

Posté(e) (modifié)

Bonjour,

J'ai fait quelques essais :

J'ai ouvert un terminal par PuTTY, je me suis connecté en administrateur puis entré la commande sudo -i.

J'ai essayé toutes les commandes tcpdump données ci-dessus en lançant à chaque fois, par le planificateur de tache, la commande 'synonet --wake 14:.......:c1 eth0', et rien n'a été reçu. 

Pourtant mon PC s'allume bien par la commande du planificateur de tache...

Si ça peut aider...

Modifié par aj13fr

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.