WakeOnLAN is a Windows tray app for waking and sleeping machines on a LAN

One application that both wakes machines and puts them back to sleep

WakeOnLAN is a Windows application built in Visual Basic .NET, and its feature list is broader than the name suggests. Beyond sending Wake On LAN magic packets, it offers shutdown, sleep and hibernate options for Windows machines, and it can shut down Linux machines using a script. That pairing is what makes it interesting for a homelab: the tool both starts a machine when you need it and stops it again afterwards, which is the loop that keeps idle hardware from drawing power around the clock.

The scheduling side is equally concrete. It can schedule wake ups and shutdowns, avoids power spikes by staggering wake-up events, and sends email notifications using the built-in scheduling system, with sound notifications when hosts change state and system tray notifications with balloon tips. Staggering is the detail that shows the author has run this in anger. Waking a rack of machines at the same instant against a switch or a UPS is a way to trip a breaker, and the tool deliberately spreads the events instead.

There is also an automatic check for latest version, and the source tree contains an AutoUpdater.NET/ directory, which is the component doing that. A desktop utility that is expected to run unattended on a machine you do not physically visit needs to tell you it still works, and the update check is the mechanism.

The README is explicit about the state of the project. The author writes that he cannot devote a lot of time to it, that he has many responsibilities with work and family, that he will try to respond to issues, and asks people not to be offended if a reply takes a long time. That is a useful signal for anyone considering depending on it.

A magic packet is a broadcast, and the network interface is configurable

The mechanism underneath Wake On LAN is a magic packet sent over the network, and the network side of the tool is where the real configuration work sits.

The network interface used for WOL packets is configurable, and the tool supports complex network environments with subnet directed broadcasts, which is the mechanism that makes a magic packet cross a router instead of stopping at the broadcast boundary. It can be used in static or DHCP addressing networks, which matters because a machine whose address changes on a DHCP lease is exactly the machine you can no longer wake by address alone.

The repository layout reinforces that this is a full desktop application rather than a single form. There are separate top level Visual Basic modules for the shell of the program, ApplicationEvents.vb for Windows event handling, Autorun.vb for the auto start with Windows behaviour, and AssemblyInfo.vb for the assembly metadata. The forms are individual files with their own designer companions and per language resource files, AboutBox.vb, CalcSubnet.vb, Crash.vb and Explorer.vb being the visible ones. CalcSubnet is the one worth noting, because it is the subnet calculation behind the subnet directed broadcast support, and Crash.vb is the handler for unhandled exceptions.

The Explorer form and the Documentation/ directory indicate that the app carries a searchable host list and its own help content, and the crash handler plus the Event Log feature together suggest the author expected long running unattended use with a post mortem trail.

Console and GUI are two front ends over the same core

The feature list promises both a command line and a GUI interface, and the source tree reflects that with a dedicated Console/ directory alongside the form files, plus a Controls/ directory for shared user interface pieces. The AlphaWindow/ directory is the other structural clue, since a background utility that has to minimize to task tray needs a small window that can be created without a visible main form.

The practical question for an evaluator is what each front end is for. The README does not document the command line syntax, and the project page at wol.aquilatech.com is where the documentation lives, since the README itself only links out and lists features. So the specific arguments of the console mode are not in the repository, which is a real gap for anyone planning to script the tool in a scheduled job.

The GUI side is better evidenced. The feature list includes minimizing to task tray, system tray notifications and balloon tips, the event log showing a history of wake ups, shutdowns and exceptions, and an AboutBox with translations into Arabic, German, Spanish, Finnish, French, Hungarian, Italian, Dutch, Portuguese (Brazil), Romanian, Russian, Chinese (Simplified) and Chinese (Traditional). The resource file naming makes the localisation approach plain: each form has a set of .resx files per culture, so the translation work is a per-form, per-language file set rather than a separate resource pipeline.

Scheduling wake ups also implies the app stays resident on the machine doing the waking, which is why auto start with Windows and task tray behaviour are first class features rather than afterthoughts.

Scanning a network for hosts, IPs and MAC addresses

The toolset includes tools to scan the network for hosts, IP and MAC addresses, and a search tool that attempts to determine if WOL is enabled on scanned Windows computers. That second capability is the one to pay attention to, because it converts a common and frustrating failure into something you can check ahead of time.

The usual reason a wake-up fails is not a bug in the sender. It is that the target machine has Wake On LAN disabled in its BIOS, in its power management settings, or in the device driver, and sometimes that the network card has been physically removed or disabled for power saving reasons. A tool that can scan a range of Windows machines and report whether they appear to have WOL enabled turns a silent no-op into a report.

The scan also gives you the addressing data you need to build a host list. A MAC address is what a magic packet is addressed to, and an IP address is what you need for the ping, shutdown and remote command features. Collecting both from a sweep is the tedious part of setting up a network of machines to manage, and the tool does it for you.

The troubleshooting tool is the third piece, and it works the opposite way. It displays incoming WOL packets, which lets you confirm that a packet you thought you sent actually arrived and was broadcast. When a wake-up does not happen, the usual sequence is to check whether the packet was sent, then whether it arrived, then whether the machine woke. This tool covers the middle step, which is where a lot of the time is lost.

Wake over the internet needs a helper on the far side

The feature list includes support for wake up over the internet using WOLAgent. This is worth understanding because it is where the security boundary sits.

A magic packet is a broadcast frame, and broadcasts do not cross a router. That is the entire reason for the subnet directed broadcast support mentioned earlier, and it is also why waking a machine at home from somewhere else needs help: the packet has to be injected on the home network, next to the target machine, by something that is already there.

WOLAgent is that something. The design implied by the naming and by the feature list is that an agent runs on the target network and forwards or relays the wake request, so the internet facing component can reach a host that is off. A relay agent on a home network is a service with network access, which means it is a decision to make with the security of that home network in mind rather than a checkbox.

The Event Log is the compensating control, and it is a good one for this use case. The feature list says the Event Log shows a history of wake ups, shutdowns and exceptions, so a relayed wake that you did not initiate is visible in the history of the machine that woke up. The cost of that visibility is that somebody has to read it, and the README does not describe any alerting beyond the email notifications tied to the scheduling system.

For a purely local network, none of this applies and the built-in subnet directed broadcast support covers the same ground without a second component to deploy.

Where WakeOnLAN does not reach

The first limit is the platform. The primary language is Visual Basic.NET and the application is a Windows program with a.NET Framework style project layout, a.vs/ directory and WinForms designer files. Shutting down Linux machines is supported, but only through a script, so the tool can ask a Linux box to go down, and it has no Linux interface of its own.

The second limit is the release history. The tagged versions are 2.12.0 on 2018-10-22, 2.12.2 on 2018-12-05 and 2.12.4 on 2019-05-05, while the master branch was pushed to on 2026-09-04. So the source is changing, but the published binaries are more than seven years old, and the automatic update check is presumably looking for a version that is not being produced at that cadence. If you need a supported build rather than a self-compiled one, this repository does not currently offer one.

The third limit is documentation. The README is a feature list and a link to the project page, with no install steps, no command line reference and no configuration file documentation. A GUI installer is the obvious deliverable given the project page, but the repository does not say how to install from source, and it does not document how the host list, the schedules and the network interface settings are stored. For a utility that holds a schedule of wake-up events, knowing where that data lives matters if the machine hosting it is ever rebuilt.

The fourth limit is licensing. The project listing marks the licence as a custom one that GitHub cannot classify, with a LICENSE file at the top of the repository. A tool that sits on a machine and is given a view of your network deserves a read of that file before it goes anywhere near a production network.

How it differs from a scheduled task or a plain script

The comparison that makes sense is with the alternatives a Windows administrator already has, and the closest one is a scheduled task.

A scheduled task can run a command at a set time. It can wake a sleeping machine only where the firmware offers a wake timer for the task, so sending the packet from another machine remains the more general approach. So a scheduled task can handle the shutdown side of the loop, and it can handle the ping, but waking a powered down machine over the network needs a sender on a different machine. That asymmetry is what WakeOnLAN fills.

The other alternative is a short script that sends the magic packet by hand, which is a well known pattern and works. The difference is in everything around the packet. The script has to know the MAC address, the target IP, the broadcast address for the subnet, and the interface to send from, and it has no record of what it sent. This application has a host list with IP and MAC addresses collected by a scan, a configurable interface, subnet calculation built in, an event log of wake ups, shutdowns and exceptions, staggering so that a batch of machines does not come up at once, and email notification through its scheduler. In other words, the packet is the easy part and the bookkeeping is the value.

A third comparison is with a dedicated wake-up service or an IP based power management card, the kind of hardware that puts an outlet on the IP network and lets you power a machine on remotely. That approach does not depend on the machine having a NIC in a sleep state that still answers a magic packet, and it works for machines with no operating system running at all. It is the right answer for a server room, and this application is the right answer for a desk. The two are not really competitors, and the README does not claim otherwise.

Editorial conclusion

WakeOnLAN fits a small Windows network where someone has to wake a machine on demand, or where scheduled wake ups and staggered start times matter more than remote administration. It does not fit a Linux-only homelab, since the primary language is Visual Basic .NET and the application is built for Windows, and it does not fit anyone who needs a signed installer or a current release train, because the newest tagged release is 2.12.4 from 2019-05-05 while the last push to master was on 2026-09-04. Before adopting it, read the LICENSE file in the repository, since the project listing marks the licence as a custom one that GitHub cannot classify, and confirm the WOL hardware and BIOS settings on the target machines, because a magic packet cannot wake a machine whose network interface has WOL disabled.

Frequently asked questions

Official sources

1. basildane/WakeOnLAN on GitHub
2. Issues
3. Project website
4. README
5. Releases