bonjour,

problème ennuyeux avec wakeonlan353,
l'envoi du réveil de poste 1 vers poste 2, poste 1 et poste 2 étant connecté ethernet, fonctionne bien. Poste 2 s'allume

Mais quand poste 1 est en wifi ça ne marche plus.

Ne voyant pas d'explication théorique j'ai posé la quetion à Orange, vu que le pont wifi-ethernet est assuré par une livebox. N'ayant pas de réponse j'ai essayé d'autres utilitaires de la famille WOL.
WolCMD ne marche pas mieux, par contre C501WakeonLan fonctionne !
C'est de plus en plus bizarre, j'ai demandé au concepteur de C501WakeonLan s'il voyait une explication, mais la réponse satisfera peut-être ma curiosité sans plus. En effet il me faut absolument une implantation sous forme de commande.

Voila je laisse cette bizarrerie gênante à ta sagacité.

J'ai essayé sans succés avec différentes cartes wifi sur poste 1, mais je n'ai pu essayer sur d'autres ponts wifi-ethernet, ni non plus logger le trafic réseau, manque de matériel.

A+ bon courage - André Calmels

[réponse de damien, le 09/03/2012 à 21h50]

Quelques questions pour essayer de comprendre la nature du problème :

• Les réseaux wifi et ethernet sont-ils sur le même brin ?
• Comment as-tu désigné la machine à réveiller : par son nom ou par son IP ? Si c'est par le nom, je te conseille de tester la dernière bêta qui corrige quelques légers problèmes.
• Si tu as spécifié un masque et un port pour réveiller ton "poste 2" (ou que tu as modifié ceux par défaut dans la fenêtre de configuration de l'appli), quels sont-ils ?
• As-tu essayé en utilisant un autre port ?
• As-tu essayé de monitorer la réception du paquet à l'aide de WolMonitor (de Depicus), par exemple ?
• Es-tu sûr que C501WakeonLan fonctionne ? D'accord tu as réussi à réveiller ton poste 2, mais les conditions de test étaient-elles les mêmes qu'avec les autres softs ? Je pense notamment au délai écoulé entre l'arrêt du poste et son réveil : avec de nombreuses box/routeurs qui n’intègrent pas de fonction "proxy wol", la table de routage est régulièrement "purgée". En conséquence, au bout de quelques minutes le WOL n'est plus possible car la box ne sait pas vers quel port ethernet envoyer la trame. Peux-tu refaire des tests pour écarter ce cas ?

A part ça, je viens de contacter le développeur pour échanger sur le sujet avec lui, j'espère qu'il aura la gentillesse de me répondre...

A suivre.

hello, moi tout fonctionne nickel en local quand je met une ip genre 192.168.1.100 (ip fixe locale).
mais pour le dns quand je met l ip machin.dyndns.org ca marche pas ... PAR CONTRE si je met l adresse ip correspondante à machin.dyndns.org (connu via whatismyip.com), là ca marche ...
comme si le logiciel n arrivait pas a faire correspondre le dns a l adresse ip ?!
une idée ???

[réponse de damien, le 02/03/2012 à 20h24]

Un utilisateur m'a effectivement signalé un problème sur un serveur 2008r2 (en 64 bits donc, et de l'IPv6). A priori, j'ai corrigé le problème dans la v3.5.4 bêta 2 que je t'invite à tester et me dire si ça fonctionne mieux. Je viens de mettre à jour le billet des versions bêta (dans lequel tu trouveras un lien de téléchargement), chose que j'avais oublié de faire.

Avec toutes mes excuses.

Re,

Soit j'ai mal vu, soit c'était bien une proposition de MAJ. Enfin voilà quoi ^^

Salutations

[réponse de damien, le 21/02/2012 à 11h53]

Oui, peu importe en fait... on ne va pas passer la semaine là-dessus !

Sur ton site et cela fait une quinzaine de jour que je l'ai installé.

[réponse de damien, le 20/02/2012 à 19h25]

Mouais, bizarre ça car je persiste à dire que cette v3.5.3 est en ligne depuis plus d'un an...

Tu es certaine que mon outil de mise à jour t'a proposé une nouvelle version de WakeOnLan ? Il arrive parfois que DipisoftUpdate ne parvienne pas à accéder à Internet (lancé avant que la connexion soit effective) alors sa fenêtre s'ouvre pour en informer l'utilisateur avec un message "Impossible de se connecter pour rapatrier le référentiel des dernière versions.". L'utilisateur peut alors cliquer sur le bouton "Précédent", éventuellement modifier sa configuration d'accès au Net (via le lien "configuration..."), puis sur "Suivant" pour retenter une connexion... Quand l'appli parvient enfin à se connecter, elle liste les applis Dipisoft installées et affiche le n° de la nouvelle version le cas échéant, ou simplement "OK" pour les applis qui sont à jour.

OkOk
Pourtant ce matin le logiciel a détecté une mise à jour et l'a installée.

[réponse de damien, le 20/02/2012 à 15h29]

C'est donc que tu devais avoir installé une ancienne version... où l'avais-tu téléchargée ? Sur mon site ou ailleurs ?

Bonjour, Premièrement félicitation et merci pour cet utilitaire indispensable.Je souhaiterai vous faire part d'une idée d'amélioration/clarification :Actuellement, le WakeOnLan et le WakeOnWan utilisent l'ip spécifiée pour la machine distante. Généralement cette ip est soit local, soit public (internet).Le clic droit sur chaque machine propose le réveil WOL et  WOW. Or on ne peux pas réveiller une machine via une ip local en WOW, ou via une ip public via le WOL (heuresement d'un coté).Deux propositions pour améliorer cette fonctionnalité :- Ajouter une case à cocher ( [] WAN) à coté du champ de saisie de l'ip (dans le formulaire "modifier/créer". Et fusionner dans le menu contextuel réveil WOL/WOW (=>Wake Up) : la bonne méthode sera choisi en fonction de l'état de "[] WAN".- Ajouter un champ IP WAN dans le formulaire  "modifier/créer" qui sera associée à la méthode WOW, et le champ IP actuel reste associée à la méthode WOL uniquement. Pour des raisons de compatibilité, peut servir pour le WOW si le champ IP WAN est vide;La deuxième proposition est plus "coûteuse" en temps de développement, mais permet d'avoir chaque machine enregistré une seule fois, avec l'ip lan et l'ip wan (si nécessaire).Cordialement,Philippe

[réponse de damien, le 20/02/2012 à 14h44]

Merci pour ces suggestions, je réfléchis depuis un petit moment déjà à la double entrée IP (publique/privée) dans les propriétés de chaque machine.

Mais comme tu le fais toi-même remarquer, l'évolution n'est pas anodine. Du coup j'hésite encore à l'implémenter dans cette "version" de WakeOnLan que je pense ré-écrire en .NET prochainement. Pourquoi ce choix ? Tout simplement car je m'aperçois que le développement en VB5 n'a plus trop d'avenir : Microsoft lui-même ne le supporte plus depuis bien longtemps. D'autre part, si l'on fait usage de composants ActiveX (comme c'est mon cas dans la quasi totalité des logiciels proposés sur mon site) dans une appli, celle-ci ne pourra être utilisée en mode 100% portable. Et ça c'est un frein relativement important pour un outil car ça lui ferme de nombreuses "portes" tel que les "Liberkey" ou autres "Framakey"...

Bonjour

hey oui encore moi ^^
Je voulais juste savoir ce que vous avez modifié sur votre logiciel, vu qu'il y a eu des mises à jour apparemment.

merci bonne journée

[réponse de damien, le 20/02/2012 à 14h27]

La version actuelle (v3.5.3) a été publiée le 11/01/2011... on ne peut pas dire que ce soit très récent !

Si tu veux connaître la liste des évolutions, tu peux la trouver sur mon site, en rubrique "blog". Tu trouveras tous les billets dans la rubrique "logiciel"...

Bonjour, félicitations pour votre utilitaire, il fonctionne parfaitement et m'est bien utile dans mon réseau sous SBS2008. Je rencontre cependant un petit souci : impossible de faire fonctionner le WOL en utilisant le nom DNS ou NETBIOS. Avec l'adresse IP par contre, aucun souci. Le problème est que le réseau est en DHCP (10h) et il faut donc aller mettre à jour toutes les adresses lorsque le bail a expiré.Avez-vous une solution à ce problème ?Merci !

[réponse de damien, le 17/02/2010 à 22h24]

L'appli permet bien entendu de réveiller les machines même lorsqu'elles sont configurées en DHCP.

Tout d'abord, il faut savoir que les "magic packets" ne sont pas envoyés directement à l'adresse de la machine, mais sont en principe envoyés à l'adresse de broadcast du réseau local. Celle-ci étant "calculée" d'après l'IP fournie et le masque de la machine (s'il a été spécifié) ou celui par défaut dans le cas contraire. En d'autres termes, si on prend l'exemple d'un réseau en 192.168.0.x, tu pourrais très bien utiliser (dans WakeOnLan) la même adresse IP pour toutes les machines. Avec le masque 255.255.255.0, l'adresse de broadcast calculée serait toujours la même : 192.168.0.255. Et quand ils sont envoyés à cette adresse, les "magic packets" sont ré-acheminés à toutes les cartes du brin.

Dans le cas de l'utilisation d'un nom (NetBIOS ou DNS) plutôt que d'une IP, l'appli commence donc par essayer de résoudre le nom fourni. S'il y a un serveur DNS sur le réseau ET que la machine "cible" est connue de lui, WakeOnLan sera donc en capacité de déterminer l'adresse vers laquelle adresser les paquets (puisqu'il récupérera l'IP de la "cible").

En revanche, si la machine est inconnue OU qu'il n'y a pas de serveur DNS, l'appli devra bien déterminer vers quelle adresse émettre les paquets. Deux cas sont possibles, selon ce qui est défini dans l'onglet "Réveil" de la fenêtre de configuration. A savoir :

• soit l'appli utilisera l'adresse de broadcast correspondant à la machine locale (celle sur laquelle est exécutée WakeOnLan),
• soit l'appli utilisera l'adresse "alternative" définie.

Voilà... est-ce que c'est plus clair à présent ?

Bonjour,

J'ai essayé avec un autre utilisateur du domaine et cela a l'air de fonctionner. Donc l'utilisateur que j'utilisais n'avait surement pas assez de privilège pour ce genre de manipulation.

Pour le EPN, on configurera l'UAC et si cela ne marche pas, bah tant pis.

merci en tout cas, parfois c'est des choses simples qui bloquent.

[réponse de damien, le 14/02/2012 à 19h01]

Content d'avoir pu te mettre sur la voie...

Bonjour,
La machine est dans un domaine. Il n'y a pas de pare-feu d'activer. Et j'ai essayé avec une authentification. Rien ne fonctionne.
Et le logiciel va servir pour plus tard pour un EPN donc les machines seront en workgroup.

bonne journée

[réponse de damien, le 13/02/2012 à 18h23]

Si la machine "cible" est dans un domaine et que le pare-feu n'est pas activé (ou ouvert juste ce qu'il faut), je ne vois pas de raison que cela ne fonctionne pas.

As-tu testé en préfixant le login avec le domaine correspondant (ex.: DOMAINELOGIN), après t'être assuré d'utiliser un compte qui a des privilèges suffisants, bien sûr... et que le mot de passe est correct.

Par contre, en workgroup prépare-toi déjà à ce que cela ne fonctionne pas, du moins si l'UAC reste activée...