PC sleeps immediately after Wake on Lan after having used sleep on lan about sleep-on-lan HOT 5 CLOSED

@SR-G @KingIzzymon Yes this is the issue i was having. I'm sorry for not articulating it better. The Wake-on-lan app on my phone was sending 3 packets but i changed that in the settings to 1 packet. Works fine now. Thanks.

from sleep-on-lan.

Ah excellent, thank you!

from sleep-on-lan.

Sorry i don't even understand the issue you are encountering.
The sleep-on-lan binary is just relying on the underlying command to put the computer at sleep (like, windows dll or linux command, depending on your platform + what you have configured in the JSON configuration file).

Once your computer has been put to sleep, the sleep-on-lan does not enter anymore in the equation (it's only the wake-up features of your motherboard + operating system that are in the equation).

Also, the sleep-on-lan binary does not "takes" ("consumes") any MAC addresses : it just reacts to packets that are received on that UDP protocol. That means : when a "wake-on-lan" command is sent over the network with a given MAC ("AA:BB:CC" = real MAC of the computer) address, SOL traps it and check (by reversing it) if it matches any local address :

• Is "CC:BB:AA" (= reversed mac) matching a local address ? If answer is no, nothing is one
• Is "CC:BB:AA" (= reversed mac) matching a local address ? If answer is yes, computer is put to sleep

So when sending "CC:BB:AA", SOL reverses it, it matches "AA:BB:CC", so configured sleep method is triggered. Nothing more.

from sleep-on-lan.

@SR-G I'm having the same issue, but the gist is using a command like shown below, its sending two packets. So when the sleep command is sent, your app responds to the first received packet and sleeps. However, when the "wake packet" is sent (using same script but actual MAC address), that's when the problem happens. The second "sleep packet" is received and your app puts the system to sleep again. Requiring a second wake command to be sent to fully wake the PC.

Could you possibly add some condition to ignore the second "sleep packet"?

mac_address="YOURMACREVERSED"

echo -e $(echo $(printf 'f%.0s' {1..12}; printf "$(echo $mac_address | sed 's/://g')%.0s" {1..16}) | sed -e 's/../\\x&/g') | socat - UDP-DATAGRAM:255.255.255.255:9,broadcast

from sleep-on-lan.

Well, so in the end, it seems somehow a client issue (why is this client sending two or three times the packets ?), and it's also why i've never had this problem over time.

In the end, i've not been able to think about a simple solution to discard the 2nd packet at resume time : when the second packet is received, how could the program determine that this is a "second packet" (and not a regular one) and that it should be discarded, whereas it will be received hours later (once the PC is back up online and the 2nd packet is dequeued from some eth internal buffers) ?

However, that exact situation (which seems way more clear now compared to initial message), has already been discussed and the conclusion at that time has been that an extra delay before going to sleep could do the trick (with a few hundreds of milliseconds of delay, allowing for the second packet to be received and easily identified at that time as "too close compared to the previous one" and hence discarded). This is what has been implemented through issue #22. This feature has to be activated through configuration, and you need at least version 1.0.6+ for this. Configuration is found below (or in previous issue or in main README.md page). It seems to have solved the issue for the initial reporters of #22.

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

(hence closing for now)

from sleep-on-lan.