Request for remote WOL feature

[Noel-M 2]

I have some Emby Android clients on the same LAN as my Emby server, and some that are external.

The Emby server sleeps when it can.

The Emby clients on the LAN wake the server quickly and seemlessly, but the remote clients do not wake the server.

I think I understand what is happenning, and have a change that can rectify this problem.

To wake the server we send a WOL magic packet to the server.

If the server has a DHCP allocated IP address, then its IP address is unreliable while it is sleeping.  The WOL magic packet contains the NIC MAC sddress which is unique.  The magic packet is broadcast to all machines on the subnet and is only accepted by a machine with that MAC address.  I presume that this is the method that Emby client uses to wake the server.

If the server has a static IP address on the LAN then we do not need to broadcast the magic packet - we can send it directly to the known IP address.  The magic packet still needs to contain the correct MAC address.  

To access the emby sever remotely the router has a static IP address (or DDNS address) and the server has a static IP address on the LAN.

My router provides a port redirection for Emby data from external port xxx to server port 8192
I also have a port redirection for WOL from external port yyy to server port 9 (udp)

I have an app on my phone that I can use to wake emby remotely, but the users of my external clients are not tech savvy and don't need that complication.

So here's my request ...

* Emby client setup should allow the user to specify a wake up port (probably 9 by default)

* Emby client determines if it is on the same subnet as the server.

  - if so, do what it currently does (broadcast?)

  - if not, send the WOL magic packet to Emby server wake up port.

[Luke 37084]

Hi, yes this idea has come up before and is certainly possible for future updates. Thanks.

[sydlexius 243]

14 hours ago, Noel-M said:

I have some Emby Android clients on the same LAN as my Emby server, and some that are external.

The Emby server sleeps when it can.

The Emby clients on the LAN wake the server quickly and seemlessly, but the remote clients do not wake the server.

I think I understand what is happenning, and have a change that can rectify this problem.

To wake the server we send a WOL magic packet to the server.

If the server has a DHCP allocated IP address, then its IP address is unreliable while it is sleeping.  The WOL magic packet contains the NIC MAC sddress which is unique.  The magic packet is broadcast to all machines on the subnet and is only accepted by a machine with that MAC address.  I presume that this is the method that Emby client uses to wake the server.

If the server has a static IP address on the LAN then we do not need to broadcast the magic packet - we can send it directly to the known IP address.  The magic packet still needs to contain the correct MAC address.  

To access the emby sever remotely the router has a static IP address (or DDNS address) and the server has a static IP address on the LAN.

My router provides a port redirection for Emby data from external port xxx to server port 8192
I also have a port redirection for WOL from external port yyy to server port 9 (udp)

I have an app on my phone that I can use to wake emby remotely, but the users of my external clients are not tech savvy and don't need that complication.

So here's my request ...

* Emby client setup should allow the user to specify a wake up port (probably 9 by default)

* Emby client determines if it is on the same subnet as the server.

  - if so, do what it currently does (broadcast?)

  - if not, send the WOL magic packet to Emby server wake up port.

There are all sorts of challenges with leveraging magic packets, even on local networks.  When the devices are all in the same VLAN, it typically works just fine.  If you have clients that say reside in an IoT VLAN that is separate from your NAS/Server, then it's still possible provided that your network allows for directed broadcasts...These are typically disabled for enterprises, large organizations, and ISPs.  Basically, this method is not going to work over the 'net.

You also mention the use of WoL over UDP (port 9, as you shared).  As you astutely observed, there is no standard way to open this port up to external access and it's typically not possible in almost every router's default configuration.  The most basic way I can think to offer such a capability is simply to have an entry under the network settings for this port, but this opens a can of worms.  Should Emby Server check/configure the OS to make sure the correct adapter is set to handle such packets?  This typically requires elevated access to perform such changes, and driver updates can definitely undo these changes (on Windows).  While this is possible for Docker, by default the Emby and LinuxServer Docker images do not run in privileged mode.  As for configuration of this on Linux & BSD systems, there are so many different ways that these OSs & Distros handle this that it wouldn't be reasonable for Emby to be able to even check a machine's configuration, let alone fix it.

I suppose some sort of tooltip or KB link could be put next to such a configuration option to indicate that the server admin is on their own to figure out how to get WOL over internet to work, but that would just invite a lot of inquiry and support requests in the forums.

[Noel-M 2]

Sometime in the last 12 months Emby for Android client changed to automatically wake a sleeping server on the LAN without user intervention.  This action is quick and elegant.  It would be nice if Emby could do the same for a remote server.

For years I have been able to wake my server from my phone, over the net, using a standard WOL app and a port redirection in my router. In the app I have broadcast turned off.

To access Emby remotely the Emby server has a static IP address on the LAN.
In the router there is a port redirection to access server port 8192.
I dont remember whether I made the router entry, or whether the Emby installer did.

I understand that most routers do not support broadcast, but broadcast is not required.
All that is needed is another port redirection that maps to server port 9, and for Emby to send a magic packet to this port.

[MrIncredible 2]

Not sure if you solved your dilemma or not, but I gave up on trying to do a straight port forward on a WOL magic packet/broadcast because I assume the MAC of the server also needs to be specified. My router does not support broadcasts. (BT Smart Hub 2).  Eventually I got around the issue using Amazon Alexa with a remote WOL plugin and using an Alexa routine to Wake my Unraid Server (running EMBY in a docker).  I further refined this by adding an Alexa skill for a URL redirect to a skill so that a http address could trigger the the WOL to the Unraid server for anyone to wake it without direct access to the Alexa skill/routine.  Works well.

 

Edited April 3 by MrIncredible

[Noel-M 2]

I don't really have a problem.  I have been waking my server remotely for years using simple WOL app on my phone.  I do not broadcast the WOL packet, simply port forward to the Emby server which has a static IP address.  Emby wakes a server on the same LAN seamlessly.  I was hoping that if Emby detected that the client and server were on different subnets it would allow me to forward the packet to an address of my choosing, thus allowing my (external, non computer literate) users to seamlessly wake the server.

[sydlexius 243]

@Noel-Mand @MrIncredibleIt's very likely the two of you are talking about the same need, but not identical conditions.  To leverage the port forwarding option, you need to leverage S3 Wake-on-LAN (suspended device).  Using S5 and S4 Wake-on-Lan (from powered off or in hibernation, respectively) can only work with a broadcast of the magic packet, and typically requires another device in the same broadcast domain in order to send that packet.  In both cases, you often will configure the CMOS settings to allow the NIC to have power while the device is off.  To wake from S3, you also may have to configure your OS.  In the case of Windows, this is typically 2 check boxes to set on the NIC.  The one to allow the NIC to wake the device; the second, subordinate checkbox tells it to only respond to magic packets (otherwise any network traffic will wake the device).