A wake up equal a sleep about sleep-on-lan HOT 22 CLOSED

I'm also having this problem

I'm using EasyWOL on iOS and have separate actions for WOL and SOL (with MAC address reversed for the latter). WOL has always worked great and PC goes to sleep just fine with the SOL command.

The problem is that when I wake it up again (through a WOL command or keyboard/mouse) the PC goes to straight to sleep again. I need repeated attempts for it to finally wake up and for me to gain access again.

from sleep-on-lan.

I figured it out. The Android Wake-On-LAN tool has a setting for number of packets to send. It defaulted to 3. Changing this to 1helped, but the final piece was removing the "Ping IP" from the Advanced Settings for the device in the list on the main screen.

But, SOL should maybe have a way to ignore bursts of sleep requests.

from sleep-on-lan.

I'm surprised, i don't have this behavior.
Which version are you using ?
How are you generating the "sleep-on-lan" magic packets (android app, home automation system, python command line tooling, ...) ?
Wouldn't it be possible for this generator to still be sending some "sleep-on-lan" requests (only triggered when the computer is awaken) ?

from sleep-on-lan.

Thank you for your answer.
I'm using the 1.0.4.
I'm using an android app to sleep and wake my computer "Wake On Lan" app.
I tried something.

1. Reboot my computer
2. Put in sleep with a magic packet and your soft
3. Put my phone in plane mode (no connection)
4. Wake my pc with the mouse
   It results each time in a sleep command :(

from sleep-on-lan.

But if I close your soft the computer stay awake

from sleep-on-lan.

Can you check what is dumped inside the logs ?
(either in windows journal for the service, either stop the service and starts the binary directly - you'll then get the logs in the console)
In order to validate what kind of event is putting back the computer to sleep.

from sleep-on-lan.

192.168.1.14 is the local IP of my Android Phone that send the sleep packet
In yellow this is the MAC adresse of my computer
In red this is the public IP of my computer

from sleep-on-lan.

So app was running. You launched the wake-on-lan command on your client at 19:57:11, PC went down in sleep mode, you resumed it, and PC has been sent again to sleep (without you doing anything) at 19:57:29, correct ?

I've never seen this behavior. Which Android WOL client are you using ? The logs tend to show that a second command has been sent (or, at least, received), but i don't see why.

from sleep-on-lan.

Yep that's it.
I tried with
https://play.google.com/store/apps/details?id=co.uk.mrwebb.wakeonlan
And
https://play.google.com/store/apps/details?id=com.bitklog.wolon
Same behavior

from sleep-on-lan.

It seems that the host computer send itself a command. ???
INFO: 2019/03/24 11:20:39 listener_udp.go:28: Received a MAC address from IP [81.49.155.XXX:56042], extracted mac [4c:cc:6a:d1:xx:xx] INFO: 2019/03/24 11:20:39 listener_udp.go:30: (reversed) received MAC address match a local address INFO: 2019/03/24 11:20:39 sleeper_windows.go:24: Executing operation [sleep], type[internal-dll]

from sleep-on-lan.

Also seeing this issue

from sleep-on-lan.

I figured it out. The Android Wake-On-LAN tool has a setting for number of packets to send. It defaulted to 3. Changing this to 1helped, but the final piece was removing the "Ping IP" from the Advanced Settings for the device in the list on the main screen.

But, SOL should maybe have a way to ignore bursts of sleep requests.

Good idea but didn"t work for me :'(

from sleep-on-lan.

This is such a cool tool, but I am having this issue as well. I am using the Alexa Wake On Lan Skill (wolskill.com) which allows you to wake a pc from an Alexa device simply by adding your mac address to it. It works perfectly for waking, but when I use this app and the reversed IP to send a sleep command, it registers the command 3 times. So when I wake it up, either by the skill or the computer's power button, it goes back to sleep a second time, and a 3rd time. Is there any way you could alter the code to prevent this?

from sleep-on-lan.

Someone find a solution or an equivalent ?

from sleep-on-lan.

I'm still using this daemon and it's executed everyday at home, and i've never encountered this problem, so i would still say that the problem is at client side (there are probably double- or even triple- commands being sent by some client ?). Or something network related ? (wifi, router, ...)

As someone said before, maybe the only possibility would be for SOL to ignore commands received at wake time ... not sure about what the logic should be (and not sure how to test it ...). The best would be for the tool to ignore requests during 10 secs after wake up, but i'm not sure it's reasy to detect the "wake up" event. And i don't think it can rely on timestamps, because the gap between first timestamp (having lead to a sleep) and second one (after wake up) will be huge.

from sleep-on-lan.

Hi, I have this issue also using Wake On Lan Android app.
I think the WOL apps send more than one instance of the packet within less than a second and sol.exe shuts down the pc before they are all passed to it so they remain in the pc memory and are sent on wake from sleep.
Would it not be possible be to get sol.exe to wait a small time for the entire set of packets to be sent before sending the pc to sleep?
This is an amazing piece of software and it would be great if it would work with these Android apps.

from sleep-on-lan.

Yes, i think your observations are probably the explanation (dual sending, and one received after the system has been put on sleep.

Indeed there is not so much possibilites :

• either to try to discard the second sending when the PC is awaken at a later time, but i'm not sure it's so easy to do (one possibility could be to try to detect if the clock has suddenly changed compared to the previous packets having been received, but not sure if that would be reliable)
• or as you suggest, to try to await a few additional hundreds of milliseconds and to discard duplicated sending at that time

I'll try to add one feature about that. I'm still using this bit of software but nearly 100% now with HTTP calls (and prior to that, with a perl shell script for the reversed WOL packets to be sent, not duplicating them), hence why i'ver never encountered this behavior.

from sleep-on-lan.

Thanks very much, I use Tasker for home automation so the only option is to use the Tasker compatible Android apps so that would be really helpful.
I was able to confirm that they do rapidly dual send (even when set to single) using
WakeOnLAN to listen.

from sleep-on-lan.

So it should (at execution time) be something like this (during local tests) :

INFO: 2021/06/28 19:48:49 listener_udp.go:31: Received a MAC address from IP [192.168.8.3:53285], extracted mac [bc:5f:f4:2b:df:2b]
INFO: 2021/06/28 19:48:49 listener_udp.go:33: (reversed) received MAC address match a local address
INFO: 2021/06/28 19:48:49 listener_udp.go:38: Extra small delay before going to sleep (to avoid dual UDP sending), during [5000ms]
INFO: 2021/06/28 19:48:50 listener_udp.go:31: Received a MAC address from IP [192.168.8.3:47137], extracted mac [bc:5f:f4:2b:df:2b]
INFO: 2021/06/28 19:48:50 listener_udp.go:33: (reversed) received MAC address match a local address
INFO: 2021/06/28 19:48:50 listener_udp.go:41: Another command is already awaiting, rejecting this one due to dual UDP sending avoidance being activated
INFO: 2021/06/28 19:48:54 sleeper_linux.go:10: Executing operation [sleep], type [echo 'sleeeeep'], command [echo 'sleeeeep']
INFO: 2021/06/28 19:48:54 sleeper_linux.go:21: Sleep implementation [linux], sleep command is [echo 'sleeeeep']
INFO: 2021/06/28 19:48:54 sleeper_linux.go:26: Command correctly executed

(huge delay here, to be able to manually tests (with linux wakeonlan command line tooling) / second UDP sending is discarded = only one sleep executed in the end)

Corresponding configuration will be :

{
  "Listeners" : ["UDP:9", "UDP:7", "HTTP:8009" ],
  "LogLevel" : "INFO",
  "AvoidDualUDPSending" : {
          "Active": true,
          "Delay": "5000ms"
  }
}

(not active by default + default delay = 100ms)

from sleep-on-lan.

Test release has been pushed here : https://github.com/SR-G/sleep-on-lan/releases/tag/1.0.5-SNAPSHOT

from sleep-on-lan.

Thanks! Works perfectly now!
Tested with Wake On Lan set to up to 3 packets ( which really sends 6 ) :

At 400ms delay there is only one Sleep command executed as all the others are rejected.

At 100ms delay and Wake On Lan sending 4 WOL packets. although 3 sleep commands are sent to the PC by sol.exe they are all sent before PC sleeps now so there is no more sleep on resume issue.

from sleep-on-lan.

Thanks for the confirmation. Closing for now.

from sleep-on-lan.