Troubleshooting Ethernet on an OS X Lion Hackintosh
Diagnose Ethernet problems on an OS X Lion Hackintosh by checking IP connectivity, controller and driver support, interface identity, and sleep behavior.
An Ethernet port can show a live cable connection in OS X Lion and still be unable to reach the router. Link status tells you the port and switch negotiated a connection; it says nothing about the IP address, route to the gateway, or DNS. Check those before replacing a driver.
On a Hackintosh, separate four possible faults: Lion does not recognize the controller; a driver loads but misbehaves; network settings are stale; or IP networking works while a Mac-specific service rejects the interface identity. Installing several kexts at once makes those faults harder to distinguish.
Preserve a working route back
Before editing kexts, bootloader settings, or network preferences, back up the installation. Copy the current bootloader configuration and extension files to another disk, too. Confirm the exact Lion release—driver support for 10.7.0 should not be assumed to cover 10.7.5—and record the Ethernet controller’s PCI vendor and device IDs. A motherboard model may not identify the controller because board revisions can differ. If you have a second bootable volume or an installer with Terminal access, confirm it boots before making a change that could leave the installation inaccessible.
Identify where connectivity stops
No usable network interface
Check the Ethernet and PCI sections in System Information, then look for a service in System Preferences → Network. A controller on the PCI bus with no usable Ethernet service points toward a driver or attachment problem. Conversely, a service named Ethernet does not prove its driver works. In Terminal, inspect what Lion created:
networksetup -listallhardwareportsifconfig -a
Match a device name such as en0 or en1 to the physical hardware port. Do not identify the adapter by its interface number alone, particularly if USB network devices have been connected before.
Link present, but no local connection
Inspect the service in System Preferences → Network. A self-assigned 169.254.x.x address usually means DHCP did not provide an address, but it does not explain why. Test the cable and router port with another machine, then renew the DHCP lease. Compare the subnet mask, router address, and DNS entries with a working device on the same network. You can temporarily assign an unused address in the correct subnet to help separate a DHCP problem from a wider link or driver fault. Avoid an address already in use, and switch back to DHCP afterward.
Test one step at a time: ping the router’s numeric address, then a reachable public IP address, then a hostname. If numeric addresses work but hostnames fail, check DNS. If the router remains unreachable despite an apparently valid address, look at the local link, VLAN or switch configuration, and driver behavior before changing DNS.
Only some services fail
If local networking and web browsing work, replacing the Ethernet driver is probably the wrong first move. Check the date and time and any proxy settings. Also check whether the affected service still accepts Lion-era clients and their TLS capabilities. A current service may refuse an older protocol even when the network interface is working.
Choose a driver by controller, not brand
Use the controller’s PCI IDs to find a kext with documented support for that device and OS X Lion build. Older Intel, Realtek, Atheros, and Broadcom controllers need not use the same driver, even on boards sold under one brand. Check first whether Lion’s own driver attaches; add a third-party kext only after confirming hardware and version support. If you are still choosing hardware rather than diagnosing an installed system, see the Lion motherboard compatibility guide.
Do not leave multiple drivers claiming the same PCI device in different extension locations. Lion may load extensions from the system installation or a bootloader-managed directory, depending on the bootloader, so record what is in both places. A system kext also needs the right ownership and permissions and a refreshed extension cache. Make one controlled change, reboot, and verify which driver loaded. Copying a file into place does not mean Lion is using it.
A working IP address and a few successful pings can hide an unstable driver. Try a sustained local file copy and check Console for recurring driver messages. If you normally use sleep, repeat the test after waking the machine; packet loss may appear only under load or after wake.
Keep interface identity changes deliberate
Some Lion-era Apple services may expect the primary built-in Ethernet interface to have a consistent identity, often en0. That does not make every en1 interface faulty; ordinary IP networking can work on en1. Investigate identity only if networking works but a service that depends on it fails. Check which device has en0, whether Ethernet is reported as built-in, and whether an old adapter left a stale service.
Deleting network configuration files to force renumbering is a last resort, not an initial connectivity fix. It can remove custom locations, static addresses, DNS entries, VPN settings, and service order. Export or write down those settings and back up the files first. After a reset, recreate the service in System Preferences and check its device name with networksetup -listallhardwareports. Do not assume it received the number you wanted.
Make the result reproducible
Record the Lion build, controller PCI IDs, active kext name and version, installation location, relevant bootloader settings, and results of the router, DNS, transfer, and wake tests. If DHCP fails only after wake, note the interface address before and after sleep and the time of the event in Console. Those observations give you something concrete to compare on the next test, rather than another untracked driver swap.
