Fixing Realtek RTL8111 Ethernet on Hackintosh High Sierra: Chip Revisions, Kexts, and ACPI Patches
Step-by-step guide to restoring wired network on an older Hackintosh running macOS High Sierra 10.13. Covers RTL8111 chip revisions, kext injection, slot identification, and ACPI wake-on-LAN fixes.
One of the most common pitfalls when resurrecting an older Hackintosh build for macOS High Sierra (10.13) is losing wired network connectivity after a kernel update or a boot-arg change. The Realtek RTL8111 series, found on countless Gigabyte, ASUS, and MSI boards from the Ivy Bridge through Haswell era, is notoriously finicky with Apple’s built-in driver stack. While the chipset is broadly supported, the specific revision of the silicon, the version of the AppleRTL8169Ethernet.kext injected by Clover, and the presence of an SSDT-UIAC.aml can all make the difference between a working en0 interface and a dead PCI-e device that doesn’t even appear in System Information.
Before you start swapping kexts or rebuilding your config.plist, confirm that the Ethernet controller is actually detected at the hardware level. Boot with verbose mode (-v) and watch for lines containing RTL8111, rtl, or Ethernet. If you see a message like RTL8111: Unknown chipset (0x0000) or the device is listed under PCI but not under Network in System Profiler, you are dealing with a kext mismatch or a missing built-in property. A clean starting point is to remove any third-party Ethernet kexts from /EFI/CLOVER/kexts/Other/ and use only the vanilla AppleRTL8169Ethernet.kext from the High Sierra installer – it ships with support for the RTL8111B, 8111C, 8111D, 8111E, 8111F, and 8111G revisions. For the RTL8111H (common on H97 and Z97 boards) you will need the RealtekRTL8111.kext version 2.2.2 or later, compiled specifically for 10.13.
Identifying the Exact Chip Revision
Run lspci -nn | grep 10ec in a terminal (you need the lspci binary from a Linux live USB or from the PCI utilities package in macOS). The output will show a four-digit device ID. The most common are 8168 (RTL8111/8168 family) and 8169 (older RTL8169). Cross-reference that ID against the Mieze/RealtekRTL8111 kext’s Info.plist to see if your revision is listed. If it is missing, you must patch the kext’s plist by adding your device ID to the IONameMatch array. This is a safe, reversible modification – you are only adding a hardware identifier, not modifying kernel code.
Kext Injection Order and Slot Identification
Clover’s kext injection order can cause the wrong driver to load first. If you have both AppleRTL8169Ethernet.kext and RealtekRTL8111.kext in the same folder, the system may load Apple’s version for a revision it does not fully support, resulting in no link or intermittent disconnects. The safest approach is to keep only one Ethernet kext at a time. Additionally, ensure that the device is assigned to built-in slot 0 by adding an SSDT-UIAC.aml or by setting built-in property to 01 via a DeviceProperties patch in config.plist. Without this, macOS may refuse to assign the en0 interface name, breaking services like iMessage and FaceTime that rely on a primary built-in network interface.
ACPI and Wake-on-LAN Conflicts
High Sierra introduced stricter power management for PCI-e devices. If your machine wakes from sleep but Ethernet does not reconnect, the issue is often a missing _PRW method or an incorrect _DSM in your DSDT. Use the grep command on your decompiled DSDT to find the Ethernet device’s _PRW – it should return a package like 0x09, 0x03 (wake from S3 on PME). If it is missing, you can inject a _PRW via an SSDT hotpatch. A simpler workaround is to disable Wake on LAN in the BIOS and in System Preferences > Energy Saver, then test sleep/wake again. If the link comes back reliably, you can leave WoL off or apply the SSDT patch.
Diagnostic Commands for Persistent Failures
When the interface appears but cannot get an IP address via DHCP, check the following:
- Kernel panic on network activity: Boot with
debug=0x100andkeepsyms=1to capture a panic log. A panic incom.apple.iokit.AppleRTL8169Ethernetpoints to a kext incompatibility – replace it with Mieze’s driver. - Interface shows “cable unplugged” when cable is connected: This is almost always a kext revision mismatch. Try forcing the link speed via
sudo ifconfig en0 media 1000baseT mediaopt full-duplex. If the link comes up, the auto-negotiation logic in the kext is faulty for your chip revision – switch to a different kext build. - No BSD name assigned: Run
ioreg -l | grep IONameMatchto see if your Ethernet controller is matched by any kext. If it matchespci10ec,8168but noen0appears, the built-in property is missing. Addbuilt-into the device’s properties via Clover’s Devices/Properties section.
Preserving a Working Configuration
Once you have stable Ethernet, back up the entire /EFI partition and also make a copy of the working kext (with its version number) to a safe location outside the boot drive. Note the exact macOS build number (17G66 for 10.13.6, for example) and the Clover revision. Some RTL8111 revisions work flawlessly on one High Sierra security update but break on the next due to changes in IOEthernetController – having a documented baseline allows you to roll back the kext or the OS update without re-diagnosing from scratch. If you later upgrade to Mojave or Catalina, test Ethernet immediately after the install before applying any third-party kexts; Apple’s native driver improved support for RTL8111 in later OS releases, and you may be able to drop the custom kext entirely.
Finally, if you are building a High Sierra machine specifically for archival or legacy software testing, consider locking the OS to the last supported build (10.13.6) and disabling automatic updates. A minor point release that changes the Ethernet stack can silently break connectivity, and restoring from a Time Machine backup is far more time-consuming than maintaining a frozen, known-good EFI folder.
