i recently set up a little home server and continue configuring it from time to time according to my needs. Now i wanted to set up a Wake-On-LAN function for my server.
I activated Ethernet wakeup on the server’s BIOS and set the wol g option with ethtool like this:
sudo ethtool -s eth0 wol g
i added a systemd daemon running the above argument on startup to ensure the server is always configured for the magic packet wakeup. Now i tried two things:
first i suspended the system to RAM because this is what i usually want to do in the future if the server is not in use with
sudo systemctl suspend
(rtcwake does not work for me for some reason)
I then use a python script on my windows mashine to send the magic package:
import socket
mac_address = bytearray.fromhex("My server's MAC address")
package = bytearray.fromhex("ff ff ff ff ff ff")
for i in range (0, 16):
package += mac_address[0:6]
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.settimeout(10)
server_address = ("My server's network address", 9)
try:
s.sendto(package, server_address)
except socket.error:
print("error while sending package")
except socket.timeout:
print("timed out while sending wakeup")
print("Sent wakeup...")
try:
response = s.recv(1024)
print(response)
except socket.error as msg:
print("Error while receiving response: ", msg)
now when i run the script as the server is suspended…nothing happens the socket times out while waiting for the answer and the server keeps sleeping.
I then tried a complete shutdown with
sudo shutdown -P +0
to check if the server would wake from this state but again nothing happens when running the script
I checked the package sent with wireshark and everything seems to be okay there is the Ethernet protocol header the IP header and the UDP header and then the correct data (6x FF 16x MAC-address)
but the server just wont wake up. I have really no idea what is going wrong and i also have no idea what logs i could check for any information. Could it be my router possibly messing things up as not sending the package to a shutdown mashine?
I use a Fritzbox 7490 as an access point for my windows mashine and the server is connected directly to the main router namely a Telekom Speedport Pro. But i can not find any configuration in the Speedport which seems to fit the WOL purpose so i am a bit lost.
First, you should of course show what WOL functionality is supported by your device:
ethtool eth0
because you can not switch on something that isn’t there at all.
Your story is not complete clear to me, you casualy mention a router, but doing this over a router is not obvious.
So you should test this from the most easy situation, step by step adding barriers.
Thus, did you check if it can be started from the same LAN when in a shutdown state. This because not all systems wake up fine when not in shutdown state (but in sleep or stand-by) and router will not by default (if at all) forward these OSI level two packets.
Sry i did not mention it i did test for the funcionality and it in deed reports support for wakeon ‘pg’ so wake on magic package should be supported.
I have my server connected directly to my “main” router and my PC connected to an access point (with an own subnet) for this router. So essentially i am sending my package from 192.168.188.20(PC) to 192.168.2.114(server) wheras 192.168.2.* is the main network of the main router and the 192.168.188.* is the subnet of the access point(the fritzbox i mentioned)
Ok, that is more info. But my questions should also trigger you to explain if (and when not, into trying) it from the same subnet. First, one must test if it works at all in the most simple environment before going to more difficult circumstances. Gathering information about what works and what not.
By the way, your story
Sry i did not mention it i did test for the funcionality and it in deed reports support for wakeon ‘pg’ so wake on magic package should be supported.
sounds trustworthy, but we still prefer the real output, so we can make our own conclusions. So next time a command is suggested, please do copy/paste it complete (the prompt/command lien, the output, the next prompt line) between CODE tags (the # button in the tool bar of the post editor). Example from my system:
boven:~ # ethtool eth0
Settings for eth0:
Supported ports: TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
boven:~ #
Thanks, but that was only a request for the future. At the moment, the test within the same LAN and subnet is more important IMHO.
It seems that even in cases where the BIOS and the NIC say they support WOL, it could be that the connections that belong to it to make things work are not available on your system (in earlier times I was informed that some connection with a wire was missing in my system by the helpdesk of the manufacturer). Thus testing if it works at all is imminent.
okay so i tested it from the same subnet and it also did not work so what would be the next possible step? How could i test if the router is the problem?
???
When it does not work from the same subnet on the same LAN, no router is involved. Only when you get it working within the same subnet, you could try and involve a router.
As I pointed out above, many problems can be the cause of it not working, inclusing the hardware of the system that is to be woken up not supporting WOL. Did you read https://en.wikipedia.org/wiki/Wake-on-LAN? It shows many points where things can go wrong. I think first is to try to find out if yor system is able to be woken up in this way at all. Documentation, manufacturers helpdesk.
Mh maybe i have a different understanding of “subnet” then? I connected both devices to the same router so they are both in subnet 192.168.2.* and then tried sending the package but nothing happened. I mentioned the router because my firtzbox has an option “Enable wake on lan for this device” when inspecting the device in the Network section of the interface but my Speedport does not have such an option. Anyways i will try look up my hardware to see if this may be the problem but i thougth ethtool would already report the support for WOL or is this not reliable?
The same subnet is when they have IP addresses/netmask in the same range, in your case I guess 192.168.2.0/24.
And they should be on the same LAN of course, because I can use that subnet in my home and you in yours (because 192.168.0.0/16 is a private address range). And they are on the same LAN when they are on the same “side” of a router (or switch, or are directly connected).
I thougt I already hinted at the fact that notwithstanding that the BOIS has it as something you can switch on/off and ethtool reporting that certain types of WOL are supported by the NIC, it is still possible that the hardware in total does not support it. I mentioned at least one example and I also pointed to a Wikipedia link. I am not going to copy/paste that Wikipedia text here. I assumee you will read for yourself.
I also suggested finding documentation about the sytem or the manufacturers helpdesk. But I am not going to suggest everything for a third time. Either you report back what you did with my suggestions (can be an explanation why you can’t or will not do something, that is exeptable), But ignoring advice does not encourage people.
Your NIC may have the WoL capabilities and report them, yet I’ve seen BIOS implementations with a default OFF for the onboard NIC. So my advice is to check the BIOS settings as well.
Unfortunately I don’t have anything to add towards solving your problem,
But a FYI
For describing machines that are on the same physical network, it’s normally called the same “network segment”
Machines are connected crossing only something like a switch or hub and normally are also set up with the same NetworkID (the part of an IPv4 address that is common to all machines in that LAN).
Subnet normally references only the logical network, and might or might not match the physical network.
When troubleshooting a problem like this,
Of course, it’s preferable to be on the same physical, not just logical network.
