Cannot wake server from sleep

[Tech127 20]

Sorry if this is in the wrong section, Luke.  Feel free to move

The issue is that I cannot wake my own server from within the home using the app for Firestick or from the Emby app itself on iOS.

I CAN send a WoL packet which will work every time, but the "wake server" function from the Firestick app just errors out and the iOS app just says "cannot connect to the selected server right now".

Fire OS v7.7.0.2

Emby  firestick v3.4.74

 

 

embyserver.txt

[Gilgamesh_48 1240]

32 minutes ago, Tech127 said:

Sorry if this is in the wrong section, Luke.  Feel free to move

The issue is that I cannot wake my own server from within the home using the app for Firestick or from the Emby app itself on iOS.

I CAN send a WoL packet which will work every time, but the "wake server" function from the Firestick app just errors out and the iOS app just says "cannot connect to the selected server right now".

Fire OS v7.7.0.2

Emby  firestick v3.4.74

 

 

embyserver.txt 19.18 MB · 0 downloads

I know that this will not answer your question but I do not believe a server should ever sleep. Blank the monitor? Yes. But the server itself as well as the drives should never sleep. I did some rather extensive research some years ago and things could change but the research found, in overwhelming numbers, that allowing drives to spin down saved very little in the way of electricity and the increased wear from the power cycles caused drives to fail at an increased rate.

But everyone has to make their own choice and I know people that not only "sleep" their server but do a full power down whenever the server is not in use.

I do know that I have fewer problems with my system than a few of my neighbors that allow there servers to sleep.

More to your question: A while ago I had a device (a camera) that just would not wake up when told. I finally found that there was a setting in my router that blocked some WOL packets. I do not know exactly how that was accessed as I had help from another neighbor who does networking for a fair sized tech company but he accessed some buried setting and suddenly the WOL started working wonderfully. There could be a setting on your router that is somehow blocking the WOL message.

[Luke 42077]

@Tech127did you click wake server in the server context menu?

[Tech127 20]

Thanks for the reply, Luke.

Yes. I did.

[Luke 42077]

Do you have a non-standard WOL setup? Currently the apps broadcast it to 255.255.255.255, port 9. If you require anything else, there is currently no way to configure that.

[Tech127 20]

I don't believe so.  I just enabled it in bios and allowed it to the nic in windows.  I can send a packet from the WoL ios app on port 9 and also from my Elan automation system on port 9.  Both work.  AFAIK, it's as simple, straightforward config as you can get.  There are no funky router/firewall rules that would interfere either

[Tech127 20]

Here the config in my phone. I hid only the MAC address in this pic

[Luke 42077]

Did you make sure the emby app is granted local network permissions on the iOS device?

[Tech127 20]

Yeah

[Luke 42077]

@sa2000are you able to reproduce?

[Tech127 20]

Thank you. And if either of you would like any additional logs, let me know!

[sa2000 674]

5 hours ago, Luke said:

are you able to reproduce?

I will look into this. My servers never sleep but will try and replicate

[sa2000 674]

12 hours ago, Luke said:

are you able to reproduce?

Yes 

 

12 hours ago, Luke said:

Currently the apps broadcast it to 255.255.255.255, port 9

Yes - for some reason this does not wake the server up but the same packet to 192.168.1.255 does 

The wolow iOS app sends the WOL packet for port 9 to 192.168.1.255 and that works ok and wakes up Emby Server. There was one WOL packet from wolow ios app that did not wake the server.

The Emby for iOS app sends the same WOL packet for port 9 to 255.255.255.255 and that does not appear to do the wake up 

Tests

Logged server activity

2025-09-03 15:42:39.019 Info HttpClient: Http response 200 from http://192.168.1.235:9197/AVTransport_1.xml after 43ms
2025-09-03 15:51:28.764 Debug UserViewsService-0HNFAT1EBDU1O:00000001: http/1.1 GET http://‌‍‍192.168.1.173‌:8096/emby/Users/xxxxxx

and the WOL packets

Emby for iOS - did not wake the server
2722	2025-09-03 15:47:57.582699	0.000000	192.168.1.225	64072	255.255.255.255	9	DISCARD	144	Discard
ffffffffffff207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9

Wolow iOS app - did wake the server
22222	2025-09-03 15:51:27.638772	210.056073	192.168.1.225	64861	192.168.1.255	9	DISCARD	144	Discard
ffffffffffff207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9

and again

emby server logged activity

2025-09-03 15:51:41.787 Error PortMapper: Error creating port map
2025-09-03 15:56:13.860 Debug SyncService-0HNFAT1EBDU2U:00000001: http/1.1 GET http://‌‍‍192.168.1.173‌:8096/emby/Sync/Items/Ready?TargetId=

Test from Emby for iOS

Emby for iOS - did not wake the server
31902	2025-09-03 15:55:10.360743	222.721971	192.168.1.225	53844	255.255.255.255	9	DISCARD	144	Discard
ffffffffffff207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9

Server woke up by moving mouse in this case

and next tests

Emby Server logged activity

2025-09-03 16:01:20.330 Debug UserService-0HNFAT1EBDU3E:00000001: http/1.1 Response 200 to ‌‍‍192.168.1.225‌. Time: 16ms. GET http://‌‍‍192.168.1.173‌:8096/emby/Users/xxxxxx
2025-09-03 16:04:43.243 Debug LiveTvService-0HNFAT1EBDU3F:00000001: http/1.1 GET http://‌‍‍dell-inspiron14‌:8096/emby/LiveTv/Channels?userId=xxxxxx

and tests - first from wolow app did not succeed

Emby for iOS - did not wake the server
69378	2025-09-03 16:01:36.645072	386.284329	192.168.1.225	64210	255.255.255.255	9	DISCARD	144	Discard
ffffffffffff207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9

Wolow iOS app - did not wake the server
74404	2025-09-03 16:03:26.940901	110.295829	192.168.1.225	61742	192.168.1.255	9	DISCARD	144	Discard
ffffffffffff207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9

Wolow iOS app - did wake the server
76974	2025-09-03 16:04:38.667675	71.726774	192.168.1.225	57403	192.168.1.255	9	DISCARD	144	Discard
ffffffffffff207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9207bd26d4ce9

Disabling windows firewall for this last test had no impact 

[sa2000 674]

The fact that I saw this broadcast to 255.255.255.255 in wireshark on another laptop means the router is not blocking the packet. Maybe windows silently discards it without logging it in firewall log - it is afterall referred to as a WAN broadcast because of the 255.255.255.255 address   Might be the NIC discarding the WAN broadcast packets?

 

 

[sa2000 674]

AI Overview recommendation

Quote

To wake a device within your network using WOL, you should send the magic packet to the device's local IP address (or its subnet's broadcast address, like 192.168.1.255). 

 

[Neminem 1518]

1 hour ago, sa2000 said:

The Emby for iOS app sends the same WOL packet for port 9 to 255.255.255.255 and that does not appear to do the wake up 

I think this would mean that Emby sends out a network wide wakeup, multi casting to all networks, lan and wan.

Emby should stay within its own subnet, and not spam everything.

Spamming  255.255.255.255 will tricker most security software and just block it.

[Luke 42077]

Oddly enough this has always worked in the past.