Host Setup

Defining your hosts is critical for successful wake-on-lan (WOL). It is also important that you know that the host you want to be able to wake up remotely must support WOL in the network hardware, and the firmware setup for the network hardware. This is beyond our scope here. Please consult the documentation for your device.

It is important to know that in general WOL only works if the wol-bliss device is on the same local network as the device you need to wake up.

The following elements are needed to set up a WOL friendly host. In the description below "host" refers to the target of your WOL magic packets.

  1. Name. You also define an identifying name for the host. This name has nothing to do with network names. It should be short, and quickly identifies the host to you. You can define up to 5 hosts, and if you only have one host for WOL the name is redundant. One thing to remember -- this name is used to keep track of the host settings.

  2. The host name or IP address. This is used to send ping packets to the host to report if it is awake or not. Technically this is not needed for sending WOL magic packets but it is nice to have the feedback in real time that the host is currently not awake, you sent the WOL MP, and seconds or minutes later the host starts responding to pings. Examples: 192.168.1.20, myhostname.

  3. The MAC address of the NIC (network interface card). This is critical -- the WOL magic packet contains this address, in fact it contains it 16 times. One bit wrong and it will not target the NIC you want.

  4. The broadcast address. WOL MPs are not sent to specific IP address, instead it is broadcast on the network on all. This explains why the MAC address is so important. Each WOL friendly sleeping NIC sees the broadcast packet and looks for a matching MAC address. A typical local area broadcast address is 192.168.1.255

  5. Number of WOL packets in the wake up call. If a host might miss a WOL packet sending multiple reduces this possibility. The gap between is set by the parameter below.

  6. Delay between WOL packets in mSec. A short gap between WOL packets. This spreads the package bundle over a longer time, again to make it less likely that all packets will be missed.

  7. Send Notifications of Dead/Alive transitions. Notification is controlled on a host by host basis. You can also control notifications via the system notification settings for this App. Two channels are used, one for alive, and one for dead. You can customize the notification sound for each in the same system settings. It is helpful for the "I woke up" sound to be distinct because the time to wake can vary and is host dependent.

  8. Length of Alive / Dead Transition Detection Buffer. One issue with these transition notifications is a missed ping or two is insignificant and you don't want a lot of false alarms. This is controlled by having a buffer with hysteresis to provide a more intelligent assessment of up / down states. This is like a thermostat that does not turn heating on and off with small temperature variations but instead heats to an upper setpoint, but waits for a drop below a lower setpoint before restarting heat. The timespan the buffer covers is the delay between pings times the buffer length. A small buffer is more reactive, and the big buffer is sluggish but very considered.

  9. Alive Threshold (< size-1). When the host has more than this number of positive pings in the buffer, the host is considered alive.

  10. Dead Threshold (> 0). When the ping buffer has this number or fewer positive responses the host is considered dead.