

Because this is a broadcast, all computers on the subnet will be targeted with the packet but only the computer that has the MAC address specified within the packet will respond/wake up. The Subnet Directed Broadcast is sent to the computer's subnet. When doing the Subnet Directed Broadcast the K1000 retrieves the MAC address and IP subnet of the target computer from its inventory which is stored in the database. Again, in my case, aliases in Network Monitor show us the host names instead. In this example the subnet is 192.168.44.0/24 with 254 possible hosts. The packet travels the network and is processed by each client on the subnet for which it was directed to. The broadcast can be identified by the "255" in the 4th part of the destination address (192.168.44.255) as this is the broadcast address for my network. The screenshot below shows a subnet directed broadcast inside our Network Monitor. This is why in general, using the Subnet Directed Broadcast method is recommended. Since the target device is in an inactive state (sleep, standby, hibernate or powered off), the ARP reply never comes back and the WOL packet is never sent. What can happen is that when the local ARP cache on the K1000 or on the router doesn’t contain an entry for a WOL target, the K1000 or the router performs and ARP request. In some environments / in a routed or non-routed environment magic packets may not be successfully delivered using the unicast method. 207 (see 4th part of IP address / in my case it is the WIN7CLIENT that gets that packet). In this example the subnet is 192.168.44.0/24 for client IP address of. The packet travels the network and is processed by only the single client on the subnet for which it was dedicated for. In my case, since I set up aliases in my Network Monitor, we could see the host name which sent the packet and received the packet. The Unicast packet can be identified by the 4th part of the destination address being not the broadcast address (192.168.44.112). It appears to be the same as the subnet-directed broadcast, but with one major exception. Anyhow, this packet, it is a UDP packet sent over port 7 from the K1000 (192.168.44.251). I am using Network Monitor from Microsoft, why not Wireshark? I don't know, I think I just like Microsoft and got used to it. The screenshot below shows a Unicast packet. Please see the below article which also describes how K1000 WOL works: Subnet Directed Broadcast works for the majority of customers just fine but not in all cases.

We have seen cases where Unicast packages arrived on the client side, but it did not wake up all clients in the list of machines even though every machine received a Unicast packet from the K1000 after further checks. I have seen 1x out of 5x environment where Unicast requests woke up the machines! However, we are mainly using and succeeding with Subnet Directed Broadcast since Unicast requires the network infrastructure to be supported and set up properly. The KBOX sends out two types of WOL requests / packets, Unicast and Subnet Directed Broadcast. The last section which is “Manual Entry” allows you to specify a single MAC address in combination with an IP address. However, this drop-down box is based on the devices / machines which were by default successfully enumerated via the “IP-Scan” within the KBOX which you can find in the “Inventory” section. The “Wake a Network Device” section allows you to choose machines from the drop-down box. This drop-down box is based on machines that are listed in the KBOX Inventory. The “Wake a Computer” section allows you to choose machines from the drop-down box. In the “Wake Multiple Devices” section you can specify / target the WOL magic packet to a group of machines which are part of the chosen label. The above screenshot shows the Wake On LAN page. Here is a great Cisco article upfront which describes steps to allow WOL traffic to pass VLANs: This article assumes that the following is in place, working and configured properly:Īll machines have a WOL compliant NIC and BIOSĪ properly configured network infrastructure *likeitsnotabigdeal* By combining all the pieces to create a WOL-ready infrastructure, you'll end up with an environment that allows networked PCs to be both responsive 24x7 and efficient from a power consumption perspective if a form of power management solution is implemented in your environment.
WOL WAKE ON LAN MAGIC PACK PATCH
An example where it becomes very useful would be a Security Patch or Service Pack that needs to be implemented as fast as possible for a set of vulnerable machines. The network request comes in the form of a magic packet which is a specially formatted network packet. Wake-On-LAN (WOL) allows properly configured machines to resume operation from a powered-off state in response to a network request.
