Ethernet Built-in 4: Fixing Network on Legacy Hackintosh

When configuring a legacy Hackintosh for macOS Sierra through Mojave, one of the most common and frustrating issues is the Ethernet controller not being recognized by the operating system. The symptom is straightforward: the Network pane in System Preferences shows no interfaces, or an interface appears but cannot obtain an IP address. Many guides reference a setting called EthernetBuiltIn or Ethernet built-in 4 — a property injected into the I/O Registry that tells macOS that a particular PCI device is the primary onboard Ethernet adapter. This article explains what Ethernet built-in 4 actually means, how to verify it, and how to fix missing or broken Ethernet on older hardware without resorting to unreliable kexts or trial-and-error patching.

What Is Ethernet Built-in 4?

In the context of Apple’s IOKit framework, the built-in property is a boolean flag attached to a network controller’s entry in the I/O Registry. macOS uses this flag to determine which Ethernet port is the primary onboard interface. The number 4 often appears in the PCI device path or in the built-in key name when multiple network controllers are present, or when the system enumerates PCI slots in a non-standard order. On a typical Intel desktop platform (e.g., Z77, Z87, Z97, X79, X99), the first Realtek or Intel Gigabit Ethernet controller is usually assigned built-in at index 0 or 1. However, after a Clover or OpenCore configuration is applied, the property may be injected as built-in 4 due to SSDT or device-properties injection ordering.

The practical consequence: if macOS sees built-in 4 instead of built-in 1 or built-in 0, the interface may still function, but certain Apple services (iMessage, FaceTime, App Store) may fail to authenticate because the system does not recognize the interface as a primary onboard device. Additionally, sleep/wake cycles can break because the power management kext expects a specific device path.

How to Check the Current Built-in Status

Before making any changes, verify what macOS currently sees. Open Terminal and run:

ioreg -l | grep -i "built-in" | grep -i "Ethernet"

This command filters the I/O Registry for entries containing both "built-in" and "Ethernet". The output will show something like:

"built-in" = Yes
"IOBuiltin" = Yes

If the output is empty, the built-in property is missing entirely. If you see "built-in" = No, macOS recognizes the hardware but treats it as a third-party PCIe card, which can cause the same issues as a missing property.

To see the full device path including the index number, run:

ioreg -l | grep -A 10 "Ethernet" | grep -E "built-in|IOPath|IOName"

Look for a line like "IOName" = "ethernet4" or "IOPath" = "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP01@1C/IOPP/pci8086,1503@0". The number after ethernet indicates which index the system assigned. If it is 4 (or another unexpected number), the injection order in your bootloader config needs adjustment.

Why Built-in 4 Appears on Legacy Hardware

On older platforms like X79 and X99, the PCIe lane layout is more complex than on mainstream chipsets. The first Ethernet controller may be connected to a PCIe root port that is enumerated after other devices (SATA controllers, USB controllers, or a second NIC). Clover’s automatic device injection (AddClockID, FixOwnership, or InjectAllUSB) can shift the order. Similarly, SSDTs that redefine PCI bridges can cause the built-in flag to land on a different index.

Another common cause: using a device-properties injection string that hard-codes built-in 4. Some older guides for Ivy Bridge and Haswell platforms included a pre-built SSDT that set the Ethernet controller to built-in 4 to avoid conflicts with Thunderbolt or FireWire controllers. This worked on specific firmware revisions but fails on others. If you have applied such an SSDT, the fix is to either remove it or modify the index.

For those building a dual-CPU system, the enumeration problem can be even more unpredictable. The Building a Dual-CPU Hackintosh on X79 and X99: A Practical Guide covers the additional ACPI and device-properties work required to stabilize network interfaces on those boards.

Fixing the Built-in Flag with Clover

If you are using Clover (r5123 or earlier for legacy OS support), the cleanest method is to inject the built-in property via the DeviceProperties section of config.plist. Do not rely on the EthernetBuiltIn key in the SystemParameters section — that key is deprecated and often ignored by macOS 10.12 and later.

1. Identify the PCI path of your Ethernet controller. Use gfxutil -f Ethernet (available from the gfxutil tool) or lspci -nn in a Linux live USB to get the BDF (Bus:Device.Function) address, e.g., 00:19.0.
2. Convert the BDF to a PciRoot path: PciRoot(0x0)/Pci(0x19,0x0) for the example above.
3. In config.plist, under DeviceProperties -> Add, add a dictionary keyed by the PciRoot path. Inside that dictionary, add a key built-in with <data>AA==</data> (which is the base64 encoding of the boolean Yes).
4. Remove any other built-in injection for the same device from SSDTs or from config.plist > ACPI > DSDT > Patches.

After rebooting, run the ioreg command again. The Ethernet controller should now show "built-in" = Yes with a predictable index (usually 0 or 1). If the index still shows 4, double-check that no other device in the same PCIe hierarchy is also claiming the built-in flag.

Fixing the Built-in Flag with OpenCore

OpenCore handles device properties differently. The built-in flag is injected via DeviceProperties -> Add in the same way as Clover, but OpenCore requires the PciRoot path to be exact and case-sensitive. Additionally, OpenCore’s Kernel -> Quirks section has a CustomSMCGuid quirk that can interfere with network device recognition on some X99 boards. If you are migrating from Clover to OpenCore on a legacy build, verify that the Ethernet controller’s class-code is set to 020000 (Ethernet controller) in the device properties; some SSDTs inadvertently change it to 028000 (network controller), which macOS treats as a wireless interface.

Diagnosing Persistent Issues

If the built-in flag is correctly set but the interface still does not work (no link light, no DHCP lease), the problem may be driver-related rather than property-related. For Intel I217-V, I218-V, and I219-V controllers on 9-series and 100-series chipsets, use AppleIntelE1000e.kext (version 3.3.19 or earlier for Sierra/High Sierra). For Realtek RTL8111/8168, use RealtekRTL8111.kext version 2.2.2 or 2.3.0, but note that version 2.4.0 and later drop support for macOS 10.12 and older.

Another overlooked cause: the DisableIoMapper quirk (Clover) or DisableIoMapperMapping (OpenCore) must be enabled if VT-d is active in the BIOS. Without it, the Ethernet controller may be blocked from accessing DMA, causing timeouts and kernel panics on wake. This is especially common on X79 and X99 boards with multiple PCIe slots populated.

For those troubleshooting sleep/wake failures alongside Ethernet issues, the Legacy Hackintosh Guide: Ivy Bridge, Haswell, Broadwell-E, and Thunderbolt 2 Fixes includes specific ACPI patches that resolve power state mismatches for onboard devices.

Testing Without Risk

Before committing changes to your bootloader configuration, create a backup of the current config.plist and any custom SSDTs. Use a USB boot stick with the modified configuration to test — this avoids rendering the main installation unbootable. After the test boot, check the I/O Registry as described above. If the built-in flag appears correctly but the network is still down, verify the kext load order and ensure no other kext is overriding the Ethernet controller’s personality.

If you have applied multiple patches from different sources (e.g., a prebuilt DMG installer), inspect each SSDT for duplicate built-in definitions. The What’s Inside an X99 DMG 2 Hackintosh Installer and How to Inspect It Safely article explains how to extract and disassemble SSDTs to identify conflicting injections. Removing redundant patches often resolves the built-in 4 issue without any additional configuration.

Finally, remember that the built-in flag is only one piece of the network puzzle. Even with the flag set correctly, a misconfigured DHCP client or a static IP with a wrong subnet mask will prevent connectivity. Always test with a known-working router and a simple ping 8.8.8.8 after making changes. If the interface gets a link light but no IP, check the BIOS setting for Wake-on-LAN and disable it — some firmware versions keep the controller in a low-power state that macOS cannot initialize properly.

Ethernet built-in 4 is a symptom, not a root cause. By methodically verifying the I/O Registry, cleaning up duplicate injections, and matching the driver to the exact controller revision, you can restore stable networking on any legacy Hackintosh.