1

I am facing a strange problem while setting up wake-on-LAN in our company network.

The following is true for the workstation to be waked-up:

  • WOL is enabled in the BIOS and in the settings of the network card
  • The router will always assign the same IP address to that workstation (MAC address)
  • The network card is configured to obtain the IP address automatically

The workstation that sends the WOL command is in the same subnet as the workstation to be waked up. Now the following scenarios happen if I try to wake up the machine:

Start Condition: Machine was turned off for one or more days

  • If I send the WOL command via network broadcast (only allowed for testing), the machine wakes up successfully
  • If I send the WOL command directly to that workstation (using IP address, subnet mask, DNS name) the machine will not wake up.
  • Only if I have started the machine manually at least once, the machine can be waked up afterwards by sending the WOL command directly to its IP address.

Does someone have an idea why the machine cannot be waked up directly via its IP address if it was turned off for a longer time and why this works if I use "Broadcast" as WOL method?

Any response is highly appreciated.

Rickson
  • 145
  • 1
  • 6
  • Sending to a specific IP-address means that it's already in the ARP-table - which can't be if it's still down. Look at this with `wireshark` or `tcpdump`. – ott-- Feb 28 '15 at 21:41
  • Thank you for your comment. This sounds like that it is not possible to use WOL with that method at all because the machine must be turned on at least one time such that the IP-address is registered in the ARP table... This would be bad in my case because broadcast is not allowed for WOL by our security policy. – Rickson Feb 28 '15 at 22:00
  • WOL-packets can be sent as UDP broadcasts too, if that helps. – ott-- Feb 28 '15 at 22:13
  • you could add a static arp entry to the machine generating the WOL request. The entry would point to the appropiate MAC for the IP in question. – Ricardo Feb 28 '15 at 22:22
  • Ricardo. Thank you for your response but at the end it is my goal to wake up multiple workstations in multiple subnets. The workstations that sent the WOL commands may or may not be in the same subnet. To make it even worse, there are multiple routers involved between the WOL sending and receiving workstation. So far I have no idea how to get this running without using broadcasts. – Rickson Feb 28 '15 at 22:31
  • Hmmm. Maybe our IT has only assigned IP addresses based on MAC addresses but no static ARP entries have been made. This could be a potential error source. I will check that... – Rickson Feb 28 '15 at 23:14
  • A great Explenation of Unicast and Multicast. The issue is the ARP cache on your network equipment. https://social.technet.microsoft.com/Forums/windows/en-US/4bf1999f-0c22-4175-8f94-8dd993ad3684/sccm-wol-and-arp?forum=configmgrgeneral – Thorbjørn H. Jan 11 '18 at 10:59

1 Answers1

3

As @ott's comment mentions, you can't send unicast traffic to a machine that isn't active on the network at that time. 'Active on the network' means different things to different devices though... to a Layer 3 device like your PC or a router it means 'this device has talked to the machine at some time in the last 4 hours' (depends on arp timeout), to a Layer 2 device like a switch it means 'the switch has seen a packet with that source mac-address some time in the last 5 minutes' (depends on mac aging time).

You state that unicast WOL works when the device has been turned on and then back off, but you don't state if it stops working at some time after the machine is shut off. This works because the router (or the WOL-packet generating PC if in the same subnet) has an arp entry (4 hour timeout) and can create a packet destined for the correct machine, however the switch either knows the port the mac-address belongs to (WOL sent within mac aging time) or has already timed out that mac-address so it treats the unknown destination as a broadcast. Once the arp entry times out, the router (or PC) will fail to encapsulate the WOL packet since it has nothing to put in the dest-mac field.

To make this work you need to use broadcasts, there is no other reliable way. To make WOL work on a different network than where your server is connected, you need to use directed broadcast packets (unicast packets sent to broadcast address of remote network, properly configured remote router will allow the packet and send it as a broadcast on the intended network).

cpt_fink
  • 907
  • 5
  • 12
  • Thank you for your comment. But from your explanation I would say that static ARP entries for the router might do the trick. I will give that a try as soon as I have the time. – Rickson Mar 02 '15 at 15:06
  • Static arp entries will enable packet formation, but they will be required for every IP address you need to WOL. Plus you will need to maintain the static entries across all L3 devices where they are configured as devices change, so it is not something I would suggest for a production network. – cpt_fink Mar 03 '15 at 06:05
  • We are talking of only 5-10 workstations that have to use WOL and the workstations are replaced every 5+ years so the maintenance work would be manageable. I hope the combination of static IP and static ARP entry will work for me. I will let you know. – Rickson Mar 04 '15 at 19:48
  • 1
    The following solutions worked: Static ARP entries and subnet-directed broadcasts. You may use one of both if you have the same scenario. Thanks for pointing me in the right direction. – Rickson Mar 30 '15 at 16:25
  • Did you have to add static arp entries on networks where you were using directed-broadcast? Or were they two separate use cases? – cpt_fink Mar 31 '15 at 04:08
  • Directed broadcasts were not allowed due to performance issues. Therefore we used the solutions with static ARP entries. – Rickson Mar 31 '15 at 15:09