Fixing Built-in Ethernet on Legacy Hackintosh: Intel I217/I218/I219 and Realtek RTL8111

When you boot a Hackintosh for the first time, the storage controller and Ethernet port must work immediately. Without a network interface, you can't download kexts, apply patches, or verify your system's identity against Apple's servers during iCloud setup. For legacy hardware running macOS Sierra, High Sierra, or Mojave, the built-in Ethernet controller is often the most stubborn component. The problem is rarely the hardware — it's almost always a mismatch between the driver version, the ACPI device path, and the macOS kernel's expectations for IONetworkingFamily.

On X79, X99, and Z170 boards, you'll typically find one of two Ethernet chipsets: Intel's I217-V/I218-V/I219-V (handled by AppleIntelE1000e.kext) or Realtek's RTL8111/8168 variants (handled by RealtekRTL8111.kext). The trick is matching the right driver version, boot-arg, and ACPI rename so the interface shows up as en0 with a stable connection and no kernel panics after wake.

Why Built-in Ethernet Fails on Legacy Hackintosh

Most Ethernet failures fall into one of three categories:

• Driver panic on boot: The kext loads but causes a kernel panic immediately after IOEthernetInterface initializes — usually because the driver version is too new for the macOS kernel's IONetworkingFamily.
• No interface in System Preferences: The kext loads silently, but no en0 appears. This is almost always a device-path mismatch: macOS expects the Ethernet controller at a specific PCI address, but your board's ACPI tables present it differently.
• Network dies after sleep/wake: The interface works on cold boot but disappears or panics after wake. This is a power-management issue: the driver does not reinitialize the PHY correctly after the controller enters D3 state.

All three have fixes, but the fixes are version-specific. Applying a driver meant for macOS Monterey to a Sierra system will cause a panic 90% of the time. Conversely, a driver from 2016 may refuse to bind to a newer I219-V revision. You must match the driver to both the macOS version and the Ethernet PHY revision.

Identifying Your Ethernet Controller

Before touching any kexts, confirm the exact device ID of your built-in Ethernet. Boot into macOS Recovery or a Linux live USB and run:

lspci -nn | grep -i ethernet

Common device IDs you will see on legacy boards:

Write down the full device ID. The driver kext uses this to match against its Info.plist. If your device ID is missing from the kext's plist, the driver will not load regardless of your other settings.

AppleIntelE1000e: Version Selection and Patches

AppleIntelE1000e is a community-developed open-source driver for Intel 82574, I217, I218, and I219 controllers. It is not the same as Apple's built-in AppleIntelE1000.kext (which only supports the 82574L found on Apple's own logic boards). The community fork has gone through many revisions, and the wrong version will panic your system.

For macOS 10.12 Sierra and 10.13 High Sierra, use AppleIntelE1000e v3.3.6 or earlier. Versions 3.4.0 and above introduced changes to the interrupt handling that cause kernel panics on Sandy Bridge and Ivy Bridge platforms. If you are running a dual-CPU X79 system, you should also read the Building a Dual-CPU Hackintosh on X79 and X99: A Practical Guide for chipset-specific interrupt mapping details.

For macOS 10.14 Mojave, you can use v3.4.2, but you must add the boot-arg -e1000e to force the driver to skip PHY detection on certain I219-V steppings. Without that boot-arg, the driver will hang during start() on many Gigabyte X99 boards.

If you encounter a panic that references AppleIntelE1000e::getPacketBufferConstraints, your driver version is too new. Downgrade to v3.3.5 and add dk.e1000=0 to your boot-args to disable DMA coalescing, which is broken on older macOS kernels.

One common mistake is installing the kext to /L/E instead of /EFI/OC/Kexts (or /EFI/Clover/kexts/Other). For legacy systems using Clover, always place AppleIntelE1000e.kext in kexts/Other and do not inject it from /L/E unless you have SIP fully disabled and are comfortable with manual kextcache rebuilds. The driver must be injected early enough to bind before the kernel's built-in AppleIntelE1000.kext claims the PCI device.

RealtekRTL8111: The 8168 Trap

RealtekRTL8111.kext by Mieze is the gold standard for Realtek 8111/8168 controllers, but the naming is misleading. The driver supports the 8111 family (which uses the 8168 PCI ID internally). However, many X79 boards from ASRock and ASUS use a Realtek 8111G or 8111H that requires a specific revision of the kext.

For Sierra and High Sierra, use RealtekRTL8111 v2.2.2. This version has stable power management and does not panic on wake. For Mojave, v2.3.0 is required because Apple changed the IOEthernetController superclass, and older versions will cause a Cannot allocate memory panic during interface creation.

If your Ethernet interface appears in System Profiler but has no IP address, open Terminal and check the link status:

ifconfig en0

If status: inactive appears even when a cable is connected, the PHY is not being initialized. Add the boot-arg rtl8111=0 to force the kext to skip the PHY register check and use a default configuration. This is a known workaround for the 8111G on ASUS P9X79 boards.

Another frequent issue is that the kext fails to load because the device is already claimed by Apple's AppleRTL8169Ethernet.kext. Check your /System/Library/Extensions for that kext and delete it (or disable it via Clover's KextsToPatch). If you leave both kexts active, they will fight over the PCI device, and neither will produce a functional interface.

ACPI Renames for Built-in Ethernet

Even with the correct kext, macOS may not assign the Ethernet controller to en0. The BSD name assignment follows the order in which IONetworkingFamily discovers interfaces. If your board has a second Ethernet port (or if the ACPI tables expose the controller at a non-standard PCI path), macOS may assign it as en1 or skip it entirely.

To force the built-in port to en0, you need two things in your ACPI patch set:

1. Device rename: In Clover, add an ACPI rename that changes the device name from GLAN or PEG0 to IGBE or ETH0 (depending on your SSDT). The exact rename depends on your board's DSDT. For most Gigabyte X79 boards, the device path is _SB.PCI0.GLAN; rename it to _SB.PCI0.IGBE.
2. Property injection: In your config.plist, under DeviceProperties -> Add, set built-in to 01000000 for the PCI device path of your Ethernet controller. This tells macOS that the device is internal and should be assigned en0.

If you are using OpenCore, the property injection is identical, but the ACPI rename is done via ACPI -> Patch. Be cautious: a miswritten rename can cause a kernel panic on boot because macOS's IORegistry expects the original path. Always test a rename by booting with -v and checking for ACPI_SMC_PlatformPlugin messages before and after the rename.

Diagnosing Ethernet Panics with Boot-args

When your Hackintosh panics during Ethernet initialization, the panic log often points to IONetworkingFamily or the specific kext. To narrow down the cause, boot with the following boot-args:

• -ne0 — disables all third-party Ethernet kexts. If the panic disappears, the kext is the problem.
• debug=0x14e — enables verbose IOKit logging. The kernel will print every kext's start() and stop() calls, showing exactly where the driver fails.
• keepsyms=1 — preserves symbol names in panic logs, making it possible to identify the exact function that crashed.

If the panic mentions AppleIntelE1000e::enableInterrupt or RealtekRTL8111::phyReset, you have a driver version mismatch. If the panic mentions IOPCIConfigurator or AppleACPIPlatform, the problem is in your ACPI tables, not the kext.

Wake from Sleep: The Final Frontier

A built-in Ethernet that works on cold boot but dies after wake is the most frustrating issue. The root cause is almost always power management: the Ethernet controller enters D3cold during sleep, and the driver does not reinitialize the PCI configuration space correctly on wake.

For Intel controllers, the fix is to add the SSDT-IGBE.aml table that re-pokes the PCI config space after wake. This SSDT is board-specific; you cannot use a generic one. For Realtek controllers, the fix is to set darkwake=0 in your boot-args and make sure HibernationFixup.kext is loaded. Some X99 boards also require rtl8111=1 to force the driver to reinitialize the PHY after wake.

If you are still experiencing wake panics after applying these fixes, verify that your Ethernet controller's power state is being managed by the kernel's ApplePMEP driver. Boot with -v and look for lines containing PME and your device's PCI address. If you see PME: device not found, your ACPI tables are not exposing the power-management event capability. In that case, you need to add a _PRW method to your Ethernet device via a custom SSDT.

Preserving a Working Configuration

Once you have a stable Ethernet configuration, back up the entire EFI folder and also archive the specific kext version you used. Future macOS updates may break compatibility, and if you later upgrade to a newer macOS version, you will need to know exactly which kext version worked. Store the kext alongside a text file listing the boot-args and ACPI patches. If you are working with a dual-CPU X79 board, you may also want to review the Dual-CPU Hackintosh Review: IMG 4881 on X79 and X99 for chipset-specific ACPI quirks that affect Ethernet.

Do not assume that a kext that works on your desktop will work on a different board with the same chipset. The PHY revision, the number of PCIe lanes, and the ACPI device path all differ between manufacturers. Always test a new kext on a cloned drive first, and keep a backup of your working configuration before changing anything.

A common mistake is assuming a kext that works on one board works on another. Always test on a cloned drive, and note the exact kext version, boot-args, and ACPI patch used. For Intel I219-V on Z170, the combination of AppleIntelE1000e v3.4.2 with boot-arg -e1000e and SSDT-IGBE.aml has proven stable across several Gigabyte boards. Write down your working config — when you upgrade to a newer macOS, you'll need that exact setup.