So this topic is a continued conversation on how to use miniWOL to wake up a Mac from sleep started by Ryan.
Since the infor is getting a little out of hand, I (Hans) have started this forum topic.
So some observations I did while testing and searching for an answer;
1) Port numbers ...
I didn't get any smarter here, except that (see end of this post) that Port 4343 seems to do something.
I've tested the default port (9), which didn't work, and the common alternative port (7), which didn't work either (same as on your setup).
In an old post I did read someone using port 4343 for WOL which did trigger did show up in the power management log:
pmset -g everything | grep Magic
You can see that the WOL packets (over port 4343) indeed arrive at the Mac.
2020-12-03 22:19:25 +0100 WakeDetails DriverReason:Enet.MagicPacket - DriverDetails:Magic packet received
(even though nothing happened - my Mac remained dark)
Note: port 9 WOL also do appear in the power management log.
2) I wonder when a Mac really goes to sleep.
When looking at the power management event with the code below, you'll see a lot of "sleep preventers".
pmset -g log | grep sleep | tail -n 10
Since I'm not very knowledgeable on the "pmset" details, there could be conflicts with different kind of sleep modes the Mac may be using.
I did disable Power Nap on my Mac for that reason, but in the end it didn't make much of a difference.
Maybe we have to wait longer.
All-in-all I wouldn't expect this to matter. At least I'd assume that a WOL magic packet should tell the Mac to "wake up", even if it's not entirely asleep.
Another thing that makes me wonder about WOL on a Mac, is the explanation of "Wake for network access":
"Even in sleep mode, wakes to provide access to shared resources, such as shared printers or Music playlists."
Granted this is a help page, and when have those ever been helpful, but it doesn't mention WOL, which you'd assume would be needed for this to work.
On the other hand the man page of "pmset" states:
"womp - wake on ethernet magic packet (value = 0/1). Same as "Wake for network access" in the Energy Saver preferences."
Confusing to say the least 😉
3) How I'm testing
So to get an idea what may be the issue, which I still haven't found, I use this Terminal statement:
date; pmset sleepnow; date; pmset -g everything | grep Magic
Which prints the date and time, puts the Mac to sleep.
Once the Mac wakes up again, it continues by printing the date and time again (soI can find those in the log) and show the "Magic packets" from the power management log.
This is what happens on my Mac Pro:
At sleep (0 seconds), the screen goes OFF, and the cooling fan keeps spinning for a few more seconds.
Sleeping for 10 seconds - Cooling fans stop.
Sleeping for 17 seconds - USB devices are turned OFF (LEDs on my keyboard go OFF).
Sleeping for 45 seconds - USB devices are powered ON again and my external disk starts spinning (I assume some Time Machine activity).
Sleeping for 97 seconds - All OFF -- USB devices go OFF again, external disk spins down, LEDs on keyboard OFF, fans OFF.
After that, when I send the WOL magic packet (port 9 and port 4343 have the same effect, so I'd stick with port 9):
USB devices are powered ON again (LEDs on keyboard ON), but the monitor remains black.
Moving the mouse doesn't do anything - screen remains black until I touch a key on the keyboard or a mouse button.
So, maybe this gets us further. Maybe you can test this on your Mac.
Once your Mac went through all these steps, and the USB devices are finally on again, maybe moving the mouse to the other screen (even though you can't see it) may turn the monitor ON again?
Still not the solution we're looking for of course, but it may get us close.
I don't think Apple is preventing WOL from non-Apple devices. The package is received (Wireshark and the Power Management log confirm this), and devices are powered again (my USB devices). Just the screen is not turned ON.
Then again, when I do touch a key on the keyboard, the Mac makes its usual mechanical sound when it starts up (I suspect the fans).
So we're not quite there yet 😞
I did see something interesting, but it would be kind-a sad if we would have to go that route;
There is a statement to mimic "user" movement (mouse/keyboard) to prevent a machine from going to sleep (or maybe even wakeup the screen?)
caffeinate -u -t 1
So I got this to work, but it feels like toooo much, but it works:
caffeinate -u -t 1
and press ENTER. Your Mac will now wake up ...
Granted, NOT the most convenient way to do this, but it does tell me the Mac is awake after a WOL, however the "user interface" isn't active yet.
In the meanwhile I have installed ShareMouse on a Windows machine and a Mac.
the suggested test I mentioned in a previous comment unfortunately did not work. 😞
p.s. I just released a new miniWOL version for Windows, since I found a tiny bug (MAC address detection) while testing 😊
Sorry for the delay – I am waiting for my forum registration email to go through and then will post in the proper forum.
As a quick note, I was able to replicate your command prompt of caffeinate and achieve the same results…it will now wake my Mac remotely from my PC. So on one hand you have solved my problem, but on the other I agree it would be much much cleaner if I could just right click on the MiniWOL icon on my PC and have this behavior mimicked when I select my Mac under network devices to wake up.
I tried creating a Macro on my keyboard to just run that command, but it’s getting hung up on inputting the password once cmd is open. Regarding the ShareMouse test…agree this doesn’t work as ShareMouse drops the connection between the two machine when one goes to sleep (you can see the ShareMouse icon change as it happens).
I wrote a little application to see if I can have caffeinate run as soon as the Mac wakes up.
Funny observation: my little program gets a notification with the wake-up message, at the correct time stamp.
But it will not execute anything until the Mac screen is awake. This is very unfortunate, because this would be an easy fix that others could run on their Mac as well. 😫
Another trick you can explore is SSH access without a password, which involves using a key - still not a great solution in my opinion, but at least it will overcome the password hurdle.
The steps are explained in the article, but the short version is this (execute on your Windows machine):
Note: I assume MYUSERNAME is your windows username, MACUSERNAME your MacOS username, and 192.168.1.100 to be the IP address of your Mac!
Make a directory for your SSH key:
Generate a key:
ssh-keygen -f C:\Users\MYUSERNAME\.ssh\id_rsa -t rsa -P ""
Send the key to your Mac (this is one single line - just in case your browser wraps the line):
type C:\Users\MYUSERNAME\.ssh\id_rsa.pub | ssh MACUSERNAME@192.168.1.100 -o StrictHostKeyChecking=No "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys || exit 1;"
After having done this, I do recommended reading the article to see what the expected outputs should be, you can send the caffeinate command through SSH (from your Windows computer) like so:
ssh MACUSERNAME@192.168.1.100 "caffeinate -u -t 1"
So if that would be the approach, which I'm still not fond off, then I could consider adding a script option (with a delay timer, or a PING test) to miniWOL.
I'd actually rather not, since the goal of miniWOL is to be simple to use and understand.
So I will try to see what else I can find to wake up the screen.
So given that I am a complete novice (though as you may have seen can follow instructions), I will say that I have been able to easily replicate all the behavior you have observed with these intermediate tests/solutions. I would agree that it would still be much better to have the functionality built directly into MiniWOL, though as a user I would say if one or two additional one-time configuration steps were necessary to get this to work well with Mac then its still a big win. For example, if you needed to direct Mac users to enable the remote login in System Preferences and provide a one time password that doesn't seem like too much to ask even a basic user (people that can't handle that probably won't even know how to search for this type of application).
Something interesting happened this morning, but unfortunately I have no idea how to check it. I used my connected peripherals to wake up my PC and then about one minute into my normal routine of checking email etc. my Mac woke up and opened the login screen on my top monitor. The Mac was asleep and in clamshell/closed mode behind the desk and had been in that state since last night. There are no peripherals plugged into it. ShareMouse and MiniWOL were enabled on both machines and are configured for startup. Something woke the Mac up...
Glad you made your way into the forum 😁
Don't worry about being a novice - the idea for miniWOL is that everybody should be able to use it, and also keep in mind that we all have been a novice, and I most certainly do not know everything either 😁
Interesting that you Mac randomly woke up. You could try and see if this will reveal anything useful (to be used after that happened):
pmset -g everything | grep Wake | tail -n 20
If it has been a while that this happened then you could try looking by timestamp - which will probably be a challenge to even guess what time that happened.
pmset -g everything | grep 12:1 | tail -n 20
This greps all lines that have "12:1" in it, so 12:10 .. 12:19 would be listed, and limites the list to the last 20 lines (tail -n 20).
As far as I can see:
WOL does indeed wake up the Mac, but only in a, what may be called, "dark wake" state.
In this dark wake state the monitor remains off and applications actually do not "run".
Interestingly certain network services (like file sharing and SSH) do seem to be running in the background (if enabled).
I tried doing a ping when my Mac is in this dark wake state, and a ping does work - it will however not wake up the Mac display.
As far as enabling Remote Access goes; I'm not a fan of enabling this for this purpose. After all, you'd open up a door that others could try to abuse.
I'm personally not worried in my network, but ya never know 😉