ASUS ProArt X870E-Creator WiFi: NIC Investigation and Wake-on-LAN on the Intel I226-V
TL;DR
If you have an ASUS ProArt X870E-Creator WiFi (or any of the related X670E/X870E ProArt boards) running Linux, and you’re trying to get Wake-on-LAN working on the onboard 2.5GbE port (Intel I226-V), you may simply not be able to. The onboard 10GbE Aquantia AQC113CS, electrically attached over PCIe, works fine. The onboard I226-V doesn’t, despite all the right OS and BIOS settings being applied.
This appears to be a platform/firmware-level limitation involving the integrated Intel I226-V on these AMD ProArt boards. Older I226 NVM firmware may be part of the problem, and AMD/ASUS standby-power handling may also be involved. The safe, vendor-supported NVM update path is not publicly accessible to normal owners, and I found no ASUS-provided BIOS or support-package path exposing an I226-V NVM update for this board.
This article documents the full diagnostic chain so you don’t have to repeat it. If you reach the same dead end, you’ll know it’s not your fault.
Hardware
- Motherboard: ASUS ProArt X870E-Creator WiFi
- BIOS: Version 2202 (latest stable at time of testing)
- CPU: AMD Ryzen 9000-series (AM5)
- OS: Ubuntu 24.04 LTS, kernel
6.8.0-111-generic - NIC 1: Intel I226-V (onboard, 2.5 GbE,
igcdriver) - NIC 2: Aquantia AQC113CS¹ (onboard PCIe-attached, 10 GbE Antigua family, link-trained at 5 GbE in this setup,
atlanticdriver)
The Problem
Wake-on-LAN works perfectly on the Aquantia 10G port. WoL completely fails on the Intel I226-V 2.5G port despite identical OS-level configuration. Both NICs have Wake-on: g set in ethtool, both have the wakeup attribute enabled in sysfs, and the BIOS has all the standard WoL-related settings configured correctly.
This investigation walks through every layer of the stack to figure out why.
Step 1 — Identify the hardware
$ lspci | grep -i ethernet
0d:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 06)
0e:00.0 Ethernet controller: Aquantia Corp. AQtion AQC113CS NBase-T/IEEE 802.3an Ethernet Controller [Antigua 10G] (rev 03)Code language: Bash (bash)Two NICs:
0d:00.0: Intel I226-V (2.5 GbE, onboard)0e:00.0: Aquantia AQC113CS (10 GbE, PCIe-attached to the motherboard, link-trained at 5G in this setup)
Step 2 — Map MACs to interfaces
$ ip -br link
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp14s0 DOWN AA:BB:CC:44:55:66 <NO-CARRIER,BROADCAST,MULTICAST,UP>
enp13s0 UP AA:BB:CC:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>Code language: Bash (bash)enp13s0= Intel I226-V (2.5G), the problem interfaceenp14s0= Aquantia AQC113CS (5/10G), the working interface
Step 3 — Verify OS-level WoL configuration
Check ethtool WoL settings on both interfaces:
$ sudo ethtool enp13s0 | grep -i wake
Supports Wake-on: pumbg
Wake-on: g
$ sudo ethtool enp14s0 | grep -i wake
Supports Wake-on: pg
Wake-on: gCode language: Bash (bash)Both show Wake-on: g (magic packet enabled). The I226 advertises more wake methods than the Aquantia: pumbg (physical / unicast / multicast / broadcast / magic) versus just pg. The running driver advertises the necessary WoL modes, so this is not a simple “driver does not expose magic-packet WoL” problem. The remaining question is whether the device remains powered and armed across shutdown on this platform.
Verify persistence after a fresh reboot
It’s not enough that Wake-on: g is set in the running session. It has to be g at the moment of shutdown. Reboot and re-check before doing anything else:
$ sudo ethtool enp13s0 | grep -i wake
Supports Wake-on: pumbg
Wake-on: g
$ cat /sys/class/net/enp13s0/device/power/wakeup
enabledCode language: Bash (bash)Wake-on: g survives the reboot, and the sysfs wakeup attribute is enabled. The OS side of WoL is genuinely armed at shutdown time. OS-level configuration is not the cause.
Step 4 — BIOS investigation
Reboot directly into UEFI setup from Linux:
sudo systemctl reboot --firmware-setupCode language: Bash (bash)This avoids the F2/Del press timing entirely on any modern UEFI system.
Advanced — APM Configuration
| Setting | Value | Notes |
|---|---|---|
| Restore AC Power Loss | Power On | Not WoL-related, but useful |
| ErP Ready | Disabled | Critical. Must be Disabled for WoL |
| Max Power Saving | Disabled | |
| Power On By PCI-E | Enabled | Required for WoL on integrated and slot NICs |
| Power On By RTC | Disabled | Not WoL-related |
ErP Ready is the single most common WoL killer on ASUS boards. When enabled, it cuts standby power to onboard devices to meet EU regulations (under 0.5W on shutdown), which breaks onboard NIC WoL while typically leaving PCIe slot WoL working. On this board it was already correctly disabled out of the box.
Advanced — Onboard Devices Configuration (search “LAN”)
| Setting | Value |
|---|---|
| Intel LAN Controller | Enabled |
| 10G LAN Card | Enabled |
Both NIC controllers are explicitly enabled at the BIOS level.
Searches that returned nothing useful
The ASUS UEFI BIOS Utility search function for this board returned no matches for the following terms:
WAKEWOLENERGYS4
The only hit for SLEEP was an AURA RGB lighting setting (“When system is in sleep, hibernate or soft off states — All On”), which is purely cosmetic. Path showed N/A, confirming it’s a global lighting attribute, not a power management setting.
PCIe settings (Advanced — AMD PBS)
All PCIe settings were left at Auto:
- CPU PCIE ASPM Mode Control: Auto
- PCIEX16_1 / PCIEX16_2 Bandwidth Bifurcation: Auto Mode
- PCIEX16_1 / PCIEX16_2 / PCIEX16(G4) Link Mode: Auto
- Chipset PCIE(G1) CTLE Optimization: Auto
- PCIe ARI Support / Enumeration: Auto
- PCIe All Port ECRC: Auto
- PCIe Loopback Mode: Auto
- Delay After PCIe Reset: Auto
Nothing here is obviously wrong. BIOS configuration is not the cause.
Step 5 — Physical standby power test
Shutdown the workstation cleanly:
sudo shutdown -h nowCode language: Bash (bash)Then observe the physical LEDs on each Ethernet port.
Result: Both LEDs go dark on shutdown.
This is initially confusing: if both LEDs are dark, neither port should have standby power, so neither should be wakeable. But the AQC113CS port, link-trained at 5GbE, still wakes from magic packets. This means the LED state is not a reliable indicator of standby power: the Aquantia controller appears to have an independent +5VSB-fed standby path that holds the WoL receiver alive even with the link LED off.
The onboard I226-V depends on motherboard chipset standby routing, and on this AMD AM5 platform, that path appears not to be reliable for keeping the WoL receiver armed on full shutdown, even with correct BIOS settings.
Step 6 — Magic packet wire capture
To eliminate “magic packet not reaching the NIC” as a cause, capture the packet on a separate host on the same broadcast domain.
Important: don’t filter on the target MAC at the Ethernet layer
A common mistake is this filter:
sudo tcpdump -i <iface> -e ether host <target_mac>Code language: Bash (bash)That does not match magic packets. The target NIC’s MAC appears inside the UDP payload, not in the Ethernet frame header. The frame is sent as a broadcast (destination ff:ff:ff:ff:ff:ff). Filtering on the target MAC at link layer matches nothing.
The correct filter is by UDP port (9 is the default for wakeonlan):
sudo tcpdump -i <iface> -e -n -X udp port 9Code language: Bash (bash)The -X flag shows hex+ASCII payload so you can verify the magic packet content.
Send a magic packet from a separate host
In this setup, a Raspberry Pi on the same LAN acted as the WoL sender. Install wakeonlan if you don’t have it:
sudo apt install wakeonlanCode language: Bash (bash)Then send the magic packet using the target machine’s MAC address directly:
$ wakeonlan AA:BB:CC:11:22:33
Sending magic packet to 255.255.255.255:9 with AA:BB:CC:11:22:33Code language: Bash (bash)Capture output
11:42:39.694323 DD:EE:FF:77:88:99 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 144: 192.168.0.50.52109 > 255.255.255.255.9: UDP, length 102
0x0000: 4500 0082 9920 4000 4011 dfdb c0a8 0032 E.....@[email protected]
0x0010: ffff ffff cb8d 0009 006e b54a ffff ffff .........n.J....
0x0020: ffff aabb cc11 2233 aabb cc11 2233 aabb ......"3....."3.
0x0030: cc11 2233 aabb cc11 2233 aabb cc11 2233 ..."3....."3..."3
... (target MAC repeated 16 times total)Code language: plaintext (plaintext)Decoded:
- Source MAC:
DD:EE:FF:77:88:99(the WoL sender on WiFi) - Destination MAC:
ff:ff:ff:ff:ff:ff(Ethernet broadcast) - IPv4:
192.168.0.50to255.255.255.255 - UDP: port 9
- Payload:
ff ff ff ff ff ff(6-byte WoL sync header) followed by the target MACAA:BB:CC:11:22:33repeated 16 times
This is a structurally valid magic packet. It reaches the wired network; WiFi-to-wired bridging is working (the capture host is wired). This proves the sender, packet format, VLAN/broadcast domain, and WiFi-to-wired bridging path are correct. It does not prove the powered-off I226 is electrically listening on the port, but it eliminates the common “bad magic packet / wrong subnet / WiFi isolation” causes.
The packet is fine. The network path is fine. The sender is fine. The I226-V is simply not responding to it during standby.
Step 7 — NVM firmware version check
$ sudo ethtool -i enp13s0
driver: igc
version: 6.8.0-111-generic
firmware-version: 2023:889d
expansion-rom-version:
bus-info: 0000:0d:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yesCode language: Bash (bash)The firmware-version: 2023:889d is the format the Linux igc driver reports for I226-V NVM. This is an older NVM version. As of 2026, community-known versions are 2.27, 2.29, 2.32, with 2.35 reported in recent OEM packages.
What this proves and does not prove
This does not prove the exact failing transistor, firmware branch, or PME transition. It proves that the usual user-controlled layers are correct: Linux exposes and arms WoL, the BIOS settings that normally block standby wake are disabled/enabled as required, and the magic packet is valid on the LAN. The remaining failure is below the level Linux users can reasonably fix: NIC NVM, board firmware, standby power routing, or PME handling.
Why you probably can’t fix this from user-space
This is the bad-news section.
- Intel does not provide a normal consumer download path for the complete I226-V NVM update package. The correct image, configuration, documentation, and recovery expectations are not publicly distributed. Intel’s NVM tooling exists across multiple operating systems; the gated part is access to the relevant I226-V materials through Intel’s RDC, which requires both an Intel Developer account and a CNDA.
- The NVM package is the real gate, not the tool. Intel’s NVM Update Utility runs on Linux, Windows, FreeBSD, and other environments. What’s missing is a supported ASUS/Intel I226-V NVM package for this board. Unofficial packages exist on community sites, but their provenance, board compatibility, and recovery path are not something I would trust on a soldered NIC without OEM backing. If you do find a package, you’d still need a dedicated boot environment to run the update safely, and the bricking risk remains.
- Real risk of bricking the NIC. Multiple users on Intel community forums, Proxmox forums, and OPNsense forums report kernel panics, NVM checksum errors, boot loops, or complete NIC failure after botched updates. Recoverable in theory (the NVM is reflashable), but not trivial in practice.
- NVM updates do not always fix WoL specifically. They tend to address link drops, packet loss, and ASPM-related freezes, all of which many I226 users want fixed for everyday use. WoL behaviour is more dependent on the chipset standby power architecture, which on AMD AM5 platforms (X670E, X870E) appears genuinely problematic for the integrated I226-V on these ProArt boards.
- It matches a pattern reported by other users on similar boards. Multiple users on Arch, Linux Mint, and the ASUS ROG forums report similar I226-V WoL failures on ProArt X670E-Creator and X870E-Creator boards. I found no ASUS-provided BIOS or support-package path that exposes an I226-V NVM update for this board, and Intel acknowledges the issue category but has not released consumer-accessible tooling.
Workaround
Use the Aquantia 10G port for Wake-on-LAN. It works reliably out of the box once configured correctly at OS and BIOS level. For the Aquantia configuration steps, see Fixing Wake-on-LAN with the Atlantic Driver on Linux. The general approach is the same ethtool -s <iface> wol g plus persistence, but unlike the I226-V, the Aquantia simply works once configured.
Persistent WoL configuration via NetworkManager
After applying the atlantic driver fix, configure Wake-on-LAN explicitly in NetworkManager rather than relying on default driver state. This makes the setting persistent across reboots, NetworkManager restarts, and profile reactivation.
First, identify the active connection profile for the 10GbE interface:
nmcli -f NAME,DEVICE,TYPE connection show --activeCode language: Bash (bash)Set Wake-on-LAN to magic packet mode, substituting the profile name from the NAME column above:
sudo nmcli connection modify "<profile-name>" 802-3-ethernet.wake-on-lan magicCode language: Bash (bash)Apply the change without dropping the link:
sudo nmcli device reapply <interface>Code language: Bash (bash)This is safe over SSH. If reapply fails on an older NetworkManager version, use connection down/up instead — but not over SSH unless you have another way back in.
Verify:
nmcli connection show "<profile-name>" | grep -i wake-on-lan
sudo ethtool <interface> | grep -E "Wake-on|Link detected"Code language: Bash (bash)Expected output:
802-3-ethernet.wake-on-lan: magic
Wake-on: g
Link detected: yesCode language: Bash (bash)As long as the atlantic DKMS patch is installed, no extra systemd service is required.
If you want to stop the system from arming WoL on a NIC that won’t honour it:
sudo ethtool -s enp13s0 wol dCode language: Bash (bash)Or leave it set; it costs nothing and keeps your options open if you ever decide to pursue the NVM update path later.
The AQC113CS port, link-trained at 5GbE on this setup but a 10GbE NIC, is the better port for a workstation use case anyway: more capable chipset, more headroom even if you never push the bandwidth. The 2.5G I226-V remains useful as a secondary interface for traffic that doesn’t need wake: second subnet, management VLAN, IoT segment, whatever fits.
Diagnostic checklist
If you’re hitting the same problem on a similar board, run through this list. If everything below is true and WoL still doesn’t work on the I226-V, you’ve hit the platform limitation and there’s no further user-space fix.
lspci | grep -i ethernetshowsIntel I226-Vat the expected PCI addressip -br linkshows the I226 interface is UP with a real linksudo ethtool <iface> | grep -i wakeshowsWake-on: gcat /sys/class/net/<iface>/device/power/wakeupshowsenabled- After a fresh reboot, both of the above are still true before you run anything else (i.e., persistence works)
- BIOS > APM Configuration > ErP Ready: Disabled
- BIOS > APM Configuration > Power On By PCI-E: Enabled
- BIOS > Onboard Devices > Intel LAN Controller: Enabled
- WoL sender is on the same VLAN/broadcast domain as the target, or the router is configured to forward directed broadcasts
- Magic packet captured on a separate host on the same broadcast domain shows valid WoL content (UDP/9, broadcast, 6 sync bytes + target MAC x16)
sudo ethtool -i <iface>firmware-version noted (NVM update path is NDA-gated)
If all of the above pass and WoL on the I226-V still doesn’t fire on shutdown -h now, you’re at the same dead end. Use the other NIC.
Before you buy
What follows is buyer advice and opinion drawn from the failure mode above.
If you’re researching this board rather than already owning one, the WoL failure is worth knowing about, but it’s not the whole story.
The Intel I226-V has a long complaint history that predates this board entirely. Its predecessor, the I225-V, shipped with the same firmware access model and the same catalogue of problems: random link drops, packet loss, ASPM-induced freezes, and unreliable wake behaviour. Intel’s response across both generations has been consistent: firmware tooling stays behind NDAs and direct OEM relationships. The chip is designed, sold to board manufacturers, soldered onto consumer products, and shipped to paying customers, none of whom can update its firmware. I found no ASUS-provided BIOS or support-package path that exposes an I226-V NVM update for this board, which suggests the OEM’s access to the update path is limited or not being surfaced to end users.
On a €700+ workstation board on the latest AMD platform, that is indefensible. WoL is not an exotic feature. It’s a basic capability that home lab users, small business operators, and remote workers rely on. Gating the fix behind a corporate legal agreement, on a chip soldered to a consumer product, is a deliberate decision by Intel, and one customers should price into the purchase or refuse to subsidise.
If Wake-on-LAN matters to your use case, do not buy a board where the primary onboard NIC is an Intel I225-V or I226-V. Not “consider whether”: don’t. The fix may well exist; it isn’t available to you, and based on Intel’s behaviour across two chip generations and five years, it isn’t going to be. The problem is chipset-specific, not brand-specific. It affects boards from every major vendor that uses these chips.
What this looks like compared to the other NIC
This board has two onboard NICs. Both are soldered to the PCB; the Aquantia is PCIe-attached electrically but integrated onto the board rather than a removable card. Both were part of the same €700 motherboard purchase. The 2.5G Intel I226-V is the basic one. The 5/10G Aquantia AQC113CS is the premium one. When I started this investigation, Wake-on-LAN was broken on both of them.
The Aquantia bug was in the kernel driver. Specifically, aq_pci_shutdown() in drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c was unconditionally clearing the PCI PME_En bit on poweroff, regardless of whether the user had configured WoL. I traced it, wrote a one-line fix, ran checkpatch.pl, and submitted the patch to the netdev mailing list. The patch is marked Cc: stable, so if accepted it is eligible for stable backporting. If accepted and backported, AQC107/108/111/112/113 users on affected stable kernels can get the fix through normal kernel updates without ever knowing it was broken.
That took an evening.
The Intel bug, to whatever extent it has a fix, lives in NVM firmware. Properly validating, updating, and recovering the I226-V NVM through Intel’s supported path appears to require gated Intel materials: an Intel Developer account and a CNDA. Linux can expose some NVM information (the ethtool -i output above shows the version), but that is not the same as having a supported update and recovery path. An ordinary private individual who buys this board has no realistic path to that NDA-gated support channel. The motherboard manufacturer can, but doesn’t push the resulting fixes through the BIOS update channel. Intel’s own support page on the WoL issue tells affected users to contact their motherboard manufacturer. The motherboard manufacturer may have access through Intel’s OEM channels, but that does not help the end user unless ASUS packages and ships the NVM update. The customer is at the end of a referral chain that loops back on itself.
The two bugs are likely comparable in technical complexity. The fix for the Intel one might be smaller than the one I wrote for the Aquantia. I will never know, because I cannot see the source.
This is the entire argument for open silicon support, lived as an experiment. Same workstation, same engineer, same week. One NIC is fixable by anyone willing to read the code. The other is not fixable by anyone who isn’t an Intel partner. Whether your hardware works comes down to which side of an NDA the bug happens to live on.
Affected chipsets and typical platforms
| Chipset | Common platforms | Notes |
|---|---|---|
| Intel I225-V | Z490, Z590, Z690, B550, X570 (2020–2022) | Same firmware gate, same complaint catalogue as I226-V |
| Intel I226-V | Z790, B760, X670E, X870E, B650E (2022–2024) | Revised silicon, same access problem |
Any board from any vendor shipping either of these chips carries the same risk profile on Linux.
Alternatives with better Linux WoL track records
| Chipset | Speed | Notes |
|---|---|---|
| Realtek RTL8125BG | 2.5 GbE | Generally well-supported by Linux’s in-kernel driver on many boards, with fewer consumer-visible firmware-update dead ends than I225/I226 |
| Aquantia AQC107 / AQC113 | 10 GbE | Now Marvell-owned; comparatively uneventful firmware history. Boring, which for a NIC is exactly what you want |
If you already own a board with an I226-V, the practical path is what this post documents: add a PCIe NIC with a better driver story and route critical traffic through it. The onboard port remains usable for secondary traffic; it just shouldn’t carry anything that depends on remote management or reliable wake.
Conclusion
The ASUS ProArt X870E-Creator WiFi has two capable NICs. On Linux on AMD AM5, only one of them reliably supports Wake-on-LAN: the Aquantia 10G. The Intel I226-V is configurable at every layer the user can reach, the BIOS is correctly set, the magic packet reaches the wire and is structurally valid, and the NIC simply doesn’t respond in standby. The user-accessible diagnosis is complete. If a fix exists, the next place to look is inside Intel’s OEM/NDA firmware path, which paying customers cannot inspect.
My personal situation is fine. I have a working NIC, the kernel patch I submitted for the other one is under review, and the system on my desk wakes up reliably. The broader situation is not fine. A €700 flagship board shipping in 2026 with a primary NIC whose firmware bugs are unfixable by the people who own the hardware is the predictable outcome of a market where consumer ethernet silicon is sold without any obligation to support it after manufacture, and where the customers most affected have the least leverage to change it.
The diagnostic chain above is the first part of the answer for anyone hitting this. The second part is harder and more political: stop buying the chip. The behaviour will continue exactly as long as the units keep moving.
¹ Strictly: the Aquantia line was acquired by Marvell in 2019, so the chip’s current branding is Marvell AQtion AQC113CS. lspci still reports it as “Aquantia Corp.” because the PCI vendor ID database lags. Both names refer to the same silicon.
