Maintaining a reliable home server setup is essential for tech enthusiasts and professionals alike, especially when remote access is a vital part of your digital workflow. One of the most efficient methods to manage power usage and availability for a Network Attached Storage (NAS) is Wake-on-LAN (WOL). For years, my NAS responded flawlessly to WOL magic packets, allowing me to power it up remotely any time I needed to retrieve files or run backups. However, that all changed after a seemingly routine BIOS update. What followed was a journey through network interface card (NIC) settings, firmware updates, and motherboard quirks to restore this critical functionality.
TL;DR
After updating my NAS’s BIOS, Wake-on-LAN stopped working because the update reset or disabled the low-level hardware settings required for the feature. The BIOS update disabled WOL by default and the NIC firmware had compatibility issues that needed to be addressed. I had to enable WOL in both the BIOS and operating system, and update the NIC firmware, before my NAS could once again be powered on remotely.
The Sudden Loss of WOL Functionality
It all started innocently enough. I updated my NAS’s BIOS to take advantage of improved fan control and some security patches. Following the update, I noticed that I could no longer wake my NAS using the WOL magic packet from my mobile app. At first, I suspected the router or my WOL client app, but everything on that end was working fine.
After trying multiple tools and triple-checking the MAC address and IP configuration, it became obvious that something had changed on the NAS itself. Since the issue started after the BIOS update, I began my troubleshooting there.
What Changed in the BIOS?
BIOS updates can often revert system settings back to their factory defaults, and that’s exactly what had happened here. A few critical WOL-related options had been turned off:
- PCIe/PCI Wake from Power Off – Disabled by default after the update.
- Deep Sleep Settings – Enabled, preventing the NIC from drawing power in low-power states.
- ErP Mode – Enabled, which disables power to the NIC during shutdown to meet energy-saving standards.
Each of these needed to be addressed in the BIOS. After re-enabling “Wake on LAN from S5” (the system’s soft-off state) and disabling ErP mode and deep sleep, I expected things to be back to normal. But they weren’t. That’s when I realized the problem ran deeper—into the firmware of the NIC itself.
Examining the NIC and Firmware Status
My NAS uses an onboard Intel Ethernet controller, and like many integrated NICs, it relies on firmware that is separate from the system BIOS. The BIOS may manage power and PCIe link states, but the NIC firmware controls its behavior when receiving special packets like WOL.
To evaluate and update the NIC firmware, I booted the system using a Linux live USB and ran the following command to identify the NIC:
ethtool -i eth0This gave me the chipset model and current firmware version. After a bit of research, I found that Intel had pushed out a firmware update recently that addressed WOL stability issues. The update tool was available on Intel’s website. After downloading and running the appropriate utility from a bootable USB drive, I successfully updated the NIC firmware.
Revisiting WOL Configuration in the OS
Updating the firmware helped partially—the NIC LEDs now stayed on even after shutdown, a sign that it was maintaining a low power state. However, my NAS still wouldn’t wake up. One final step was configuring the NIC behavior in the OS to accept magic packets. On Linux-based distributions, you can set this using ethtool:
sudo ethtool -s eth0 wol gTo make this setting persist across reboots, I added the following to a system startup script:
#!/bin/sh
ethtool -s eth0 wol g
On systems like Ubuntu, this can go into /etc/rc.local or be handled via a systemd service if preferred.
Troubleshooting Tips and Final Checklist
In case you’re facing similar WOL issues after a BIOS or firmware update, here’s a quick checklist that may help:
- BIOS Checks:
- Ensure WOL is enabled from shutdown (S5 state).
- Disable ErP Mode.
- Check for ‘Deep Sleep’ settings and disable them.
- NIC Status:
- Boot into a live OS and use tools like
ethtoolto check current WOL state. - Update your NIC firmware using tools from the manufacturer.
- Ensure wake events are trigger-enabled on your OS.
- Boot into a live OS and use tools like
- Network Configuration:
- Ensure routers are not blocking broadcast WOL packets.
- Confirm MAC address and that IP/MAC bindings are preserved after shutdown.
- Use broadcast IP for magic packets if needed (e.g.,
192.168.1.255).
Lessons Learned
This experience served as a reminder that BIOS updates, while often essential for security and stability, can reset or alter hardware settings that are critical for more obscure features like Wake-on-LAN. Additionally, NIC firmware plays a pivotal role that’s often overlooked by average users.
If your NAS or server stops responding to WOL, it’s worth walking through both BIOS and NIC firmware diagnostics before assuming hardware failure. These features often rely on perfectly aligned configurations across hardware and software layers.
Final Thoughts
Wake-on-LAN remains a powerful tool for managing devices remotely, especially for users who run NAS setups or headless systems that don’t need to be on 24/7. However, its reliability hinges on multiple dependencies—from BIOS options and power delivery settings to NIC firmware versions and OS-level configurations.
If you’re like me and enjoy having remote control over your home lab or file server, keeping an eye on these small details can make the difference between a responsive system and frustrating downtime. Thankfully, after adjusting the updated BIOS, flashing the NIC firmware, and tuning OS-level settings, my NAS is back online and waiting for wake commands—just like the good old days.