Wake-On-LAN with Apple silicon

UPDATE: Thanks to everyone who contributed thoughts! I gave up on WOL for this situation, it does not seem to work. But having the computer shut the video display without fully sleeping does work to keep Teamviewer access alive. Except it was failing every morning.

Teamviewer support sent me a log output that showed the computer was, in fact, going to sleep at 4am, which corresponded to a backup process that runs and then sleeps the computer. After telling it to follow the system settings TV access now appears to be consistent!

********************************************************

Hello! I use Teamviewer and sometimes want to access my office computer (M1 Mini) from a remote device. This works great, except if the Mini has gone to sleep. Teamviewer provides Wake-on-LAN functionality through their interface, but it does not work in this case. The Teamviewer client knows that the Mini is asleep, but the wake function does nothing.

After a lot of experimenting to no avail, Teamviewer support finally said: “Apple Silicon Macs (including M1 Mac mini) do not reliably support third‑party Wake‑on‑LAN while sleeping, due to how macOS manages power and network interfaces during sleep. This is a platform limitation and not something TeamViewer can override.”

Yes, all the settings are correct. I also tried a standalone WOL utility on my phone which did not work. So I suspect Teamviewer is right, but I’m wondering if anyone here can confirm this, or knows of a workaround?

Thanks!

1 Like

It’s not helpful, I know, but in all the years WoL has been around, it has never functioned for me reliably. I suspect corporate firewalls also play a part but Teamviewer may be correct blaming Apple Silicon.

Thanks, Tony. This is on my home network, so I control the firewall settings. And when I tried the phone app that was via Wifi on the LAN side, so not going through the firewall at all. It seems like WOL is a protocol that requires several pieces to be in place in order to work. It would not surprise me if Apple has made it non-functional, intentionally or not.

I solved this problem by turning on Settings / Energy / Prevent Automatic Sleeping When the Display is Off.

I use Screens (and Screens Connect) by Edovia rather than TeamViewer, and it works perfectly for me. That said, I want the Minis to be on all of the time anyway - I use them to back up to from other computers, to sync files between different computers using the app Syncthing, and to filter spam on a couple of email accounts using SpamSieve.

2 Likes

I turned on that function and tried it just now, no better. I suppose if I turned the display off it would help because the computer would not sleep, but I prefer to leave the display on and let everything sleep on its own. Guess I can have the Mini not sleep at all, but then the display will stay up all the time (with desktop of screensaver). Thanks for the suggestion!

Maybe useful: Lock Screen settings to turn display off after x minutes inactive, keep the Mini from sleeping… hm.

Well now, that is interesting. I already have it set for screensaver at 30mins and turn off the screen at two hours. And that does happen. But the Energy Saver panel no longer has an option to never sleep the computer, or set the sleep time, so I don’t actually know when it occurs.

So maybe if I turn on “Prevent automatic sleeping when the display is off” that will actually prevent it from sleeping on its own. I interpreted that to mean when the display is literally turned off, which I don’t want, but that term is ambiguous. I’ll give it a try, thanks!

Consider using the pmset (and man pmset) command. As Apple changes which options are available in settings I have had to use this command to clear/reset and set values.

My current settings on my M2 Studio, for example:

> pmset -g
System-wide power settings:
 SleepDisabled		0
Currently in use:
 standby              0
 Sleep On Power Button 1
 autorestart          0
 powernap             1
 networkoversleep     0
 disksleep            10
 sleep                0 (sleep prevented by powerd)
 ttyskeepawake        1
 displaysleep         10
 tcpkeepalive         1
 lowpowermode         0
 womp                 1   
>

womp (wake on ethernet magic packet) is probably the one you need to check.

1 Like

If your Mac has the setting to Wake for network access, then it should support WOL.

But what you didn’t say is how your Wake On LAN signal is supposed to get from where you’re sending it (remote system, TeamViewer server, or app on phone) to your office computer. Wake-On-LAN packets do not easily traverse routers and firewalls!

The basic problem is that Wake-on-LAN is based on broadcast messaging – a packet sent to every device on the local network – so generally only works when both devices are on the same subnet.

If the computer you’re trying to wake up is on your home network, connected to a router you control, sometimes the router has a way that you can access its admin interface from the WAN side and ask it to send the WOL magic packet to a particular device. Aside from that, you’re probably out of luck.

Note that this is where Apple’s MobileMe/iCloud Back to My Mac service was useful. It had a way, I think, for a remote Mac to wake up the Mac you wanted to connect to.

2 Likes

Thanks, that’s a good tip in general! My WOMP is set to 1. Out of curiosity I did a little test, the WOMP function is toggled by “Wake for Network Access” in the Energy control panel. So that’s at least doing what it should.

1 Like

Thanks, Michael. I knew about the “magic” packet limitations crossing between networks. But the phone app I was using to test is on the same subnet as the Mac, on the LAN side, so that limitation should not apply. The app could see the Mac (using ping as a verifier) but the WOL did nothing.

If WOL did work locally I’m not sure how Teamviewer handles getting the packet from the internet to the LAN, but supposedly they can do it. Even when I had the router forward the WOL port to the Mini it did not help. I’ve read conflicting tales about whether WOL should be port-forwarded or not, whether it is only broadcast, or what.

This idea does work! It was the ambiguity of “when the display is off” that led me to think this setting would not help, since I was not going to turn off the display externally. But it actually means ““when the Mac turns off the video output” it will keep the computer awake, which is a reasonable workaround.

And it might also solve another odd problem, which is that sometimes (rarely) when I try to wake the Mini in the morning and it will not respond to a keystroke. Have to push the power button momentarily to wake it. No idea what this is about, but it doesn’t really matter.

1 Like

My 2017 iMac often will not promptly wake to a (wired) keyboard press. I too briefly press the power button to wake it.
With your remote waking issue I am guessing Apple are nervous about hacking these days and so are not enthusiastic about supporting it, as they used to do with Back-to-my-Mac.

It only happens once in a random while, screwy.

Meanwhile, this morning Teamviewer thought the Mini was asleep even though it was supposed to be awake with the screen off. Maybe Teamviewer is using video status to detect sleep mode, rather than some other indicator.

If your remote device is an Apple device, it may be worth giving Screens from Edovia a try. You’d install the free Screens Connect app on the Mini and use the Screens app from the remote device. There is a free trial for all OSes for Screens, though it is not a free app.

The protocol is surprisingly simple. A magic packet is 6 bytes of all-ones (hexadecimal FF FF FF FF FF FF, followed by 16 repetitions of the target computer’s Ethernet MAC address.

The pattern can be carried by any protocol, as long as it is delivered to the target computer. It can be a raw Ethernet frame, a UDP packet or anything else. (Connection-oriented protocols like TCP won’t work, because you can’t establish a new connection with a sleeping computer.)

It doesn’t have to be an Ethernet broadcast packet. This is commonly used for simplicity, but it can be any packet that will ultimately be delivered to and received by the target computer.

So, if the target computer is exposed to the Internet (e.g., a public IP address, a fixed IP address-mapping in your router, or a port-mapping rule), and the sender knows the computer’s MAC address, sending the packet is trivial.

If your ISP supports IPv6 (e.g., Comcast Xfinity does), then your computer almost certainly has a public IPv6 address, to which a remote wake-on-LAN too can send a UDP packet with the WOL pattern.

If not, then you should probably designate one port for forwarding this packet. Since there is no designated port for this, you can pick anything that’s not being used. Of course, if you have multiple computers you want to wake, you’ll need to map a different port for each one.

Some commonly-used port numbers for this (what you probably want to map the port onto) are:

  • 0 - invalid/reserved
  • 7 - echo protocol (used by ping commands)
  • 9 - discard protocol (all packets are discarded on receipt)

See also: Wikipedia: Wake-on-LAN / Magic packet.

Regarding Teamviewer, I am unfamiliar with this product, but…

The client app, when registering itself with the remote server, should have no problem sending your MAC address to the server. So the remote server can easily fashion a WOL packet.

If your computer has a public IP address (likely if you have IPv6, less likely if it’s v4), it can send a packet directly to that address.

If the client uses UPnP to set up port-forwarding in your router, that mapping may persist when the host goes to sleep. So the server can send the WOL packet to that port.

1 Like

Unfortunately my remote device is often my Android phone. But I have Teamviewer for other purposes anyway, this just happens to be a handy capability when I’m out and realize I forgot to do something on my office machine.

Thanks, David, for the concise summary. I set it up pretty much as you describe, using port 9 UDP based on what Teamviewer suggested. But it never worked, which is when they said it’s a limitation with the Apple Silicon machines. Unfortunately their documentation is out of date which wasted a lot of effort. Since I can’t get WOL to work on the local network either, I suspect they are correct.

The easiest solution is to just set the Mac to never sleep but let the display do so. Sleep probably uses less energy…but mu guess is the difference is less than 10 bucks a month on your power bill. I could never get WOL to actually work reliably, just like Time Machine to network drives…so I just worked around the problem.

1 Like

I was never blessed to get it to work reliably from away from home but use Screens all the time on my home LAN.