New Driver for Realtek RTL8111

[Henties]

@Mieze Version 3.0.1 of your RealtekRTL8111.kext wörx like a dream.

 

If one has a situation, as I am having under Alder Lake, that the MAC address field remains unoccupied, your code now plugs in 

an arbitrary MAC address. Feutibul indeed.

 

In order to be able to use the factory assigned MAC address, in preference to the one that your code plugs in, one just has to

enter that into the fallbackMAC placeholder of the info.plist and voila everything is golden.

 

I see another advantage in this method.

 

If for one or other reason one were to change the NIC, same kind and controlled by the same RealtekRTL8111.kext, one would be able to continue with the same MAC address as was assigned to the original NIC.

 

The caveat being that one must now ensure not to plugin the original NIC into the PCIe slot of another computer, on the same network as that would result Confucius to rule, therefore a bit of care would be required to prevent that happening.   

 

Thanks a lot for your dedication and help, looking forward to your modified LucyRTL8125Ethernet.kext, so that the onboard NIC (Realteh 2.5 GbE) of my Alder Lake hack can also operate with the

OC --> config.plist --> Kernel --> Quirks --> DisableIoMapper set to NO

 

Greetings Henties

 

 

Edited December 5, 2025 by Henties

[arsradu]

19 hours ago, Mieze said:

@arsradu First, using two interfaces simultaneously is a very bad idea and can cause a lot of trouble. All interfaces of a host share the same DUID, which means that DHCPv6 will try to assign the same  IPv6 address to all of them. Of course, this won't work and might result in messed up routing tables. Routing problems or address conflicts may also occur with IPv4. Even with different addresses, there might be problems because of applications getting confused. 

 

Second,  there is no dependancy between drivers. If using multiple interfaces causes trouble, a driver problem can be ruled out.

 

Third, auto configuration sometimes results in an unstable connection causing reconnects. Using EEE or flow control might result in frequent disconnects. I recommend to use flow control only when necessary to avoid these kind of problem, because it can cause transmitter stalls, so that the driver has to initiate a reset to recover from that situation.

 

Mieze 😺

 

Hey Mieze!  

 

I know we're not comparing "apples to apples"...sort of speak, but...there are a couple of things that still make me confused about this issue.

1. I don't remember having this issue before, when using OCLP. Of course, that was with Sequoia. So I'm taking that into account, as well.
2. I don't remember having this issue with Ethernet driver v2.5.0 (with VT-D disabled). I can test this more, just to confirm. But for this case, AppleBCMCompanion will need to be set up in a different way so it works with VT-D disabled. So...not sure how accurate, or relevant, that test would be.
3. I've tested this scenario on an M1 Mac Mini, running Tahoe 26.1, and it seems to handle both interfaces being turned on at the same time gracefully. From what I can tell, it will prioritise Ethernet over WiFi when available, but yeah, no disconnects, no issues opening pages. Nothing like that. Everything seems to be going perfectly fine.

So my question here is: is this a specific issue to hacks? Is this a hardware issue...? Cause...it doesn't seem to be either one of them, since the same computer worked fine before. :))

So...something has changed.

And for what I can tell, the following things have:

1. the OS (Tahoe vs Sequoia)
2. VT-D enabled vs disabled.
3. drivers (both for WiFi and Ethernet)

So one of these, or a combination of them, seems to be causing this kind of issues.

 

As for the last part, I'm not sure if I'm using EEE or flow control (I'm honestly not quite sure what they are or how to enable/disable them). So, if default state for them is Off, then...they're probably off already. :))

 

But, the question remains: am I the only one with this setup (both WiFi and Ethernet enabled), who's having this kind of issues...? Cause if so, then it must be something specific on my side. If not, then it's probably something else.

Edited December 5, 2025 by arsradu

[Mieze]

@arsradu A Hackintosh is always a unique machine and there are several factors which might affect networking, inside the system and from the network side. Unfortunately I can't give you an explanation with the information I have. The driver has been designed and tested to work with and without AppleVTD, but in the end there is one factor, which lies beyond my scope: there are several mainboards which refuse to work properly with AppleVTD, even with a patched DMAR. That's just bad luck and there is nothing I can do about it. 🤷‍♀️

 

Mieze 😺

[arsradu]

16 hours ago, Mieze said:

@arsradu A Hackintosh is always a unique machine and there are several factors which might affect networking, inside the system and from the network side. Unfortunately I can't give you an explanation with the information I have. The driver has been designed and tested to work with and without AppleVTD, but in the end there is one factor, which lies beyond my scope: there are several mainboards which refuse to work properly with AppleVTD, even with a patched DMAR. That's just bad luck and there is nothing I can do about it. 🤷‍♀️

 

Mieze 😺

 

Thank you, Mieze!  

 

Following up on your message above, which gave me a hint in the right direction (thank you!), and after digging around for a little bit, I found an option in OC config called DisableIOMapperMapping (not DisableIOMapper). Which....seems to improve reliability quite a lot, and allow for both WiFi and Ethernet to work together seamlessly.

 

So, my current setup looks like this:

1. VT-D enabled in BIOS
2. DisableIOMapper set to Disabled (unchecked)
3. DisableIOMapperMapping set to Enabled (checked)

From the OC configuration PDF, we can see what this option does:

8. DisableIoMapperMapping
Type: plist boolean
Failsafe: false
Requirement: 13.3 (not required for older)
Description: Disables mapping PCI bridge device memory in IOMMU (VT-d).
This option resolves compatibility issues with Wi-Fi, Ethernet and Thunderbolt devices when AppleVTD is
enabled on systems where the native DMAR table contains one or more Reserved Memory Regions and more
than 16 GB memory is installed. On some systems, this quirk is only needed when iGPU is enabled.
Note 1 : This quirk requires a native DMAR table that does not contain Reserved Memory Regions or a substitute
SSDT-DMAR.aml in which Reserved Memory Regions have been removed.
Note 2 : This option is not needed on AMD systems.

 

So that seems to fix it for me.   Hopefully this will be useful to other people as well.

Edited December 6, 2025 by arsradu

[Mieze]

Attached you'll find an update of RealtekRTL8111 (build 3.0.3), which fixes a bug of build 3.0.2 that may cause stability issues under low memory conditions.

 

Mieze 😺

RealtekRTL8111-V3.0.0-build-3.0.3.zip

[deeveedee]

On 12/6/2025 at 9:24 AM, arsradu said:

8. DisableIoMapperMapping
Type: plist boolean
Failsafe: false
Requirement: 13.3 (not required for older)
Description: Disables mapping PCI bridge device memory in IOMMU (VT-d).
This option resolves compatibility issues with Wi-Fi, Ethernet and Thunderbolt devices when AppleVTD is
enabled on systems where the native DMAR table contains one or more Reserved Memory Regions and more
than 16 GB memory is installed. On some systems, this quirk is only needed when iGPU is enabled.
Note 1 : This quirk requires a native DMAR table that does not contain Reserved Memory Regions or a substitute
SSDT-DMAR.aml in which Reserved Memory Regions have been removed.
Note 2 : This option is not needed on AMD systems.

 

Not sure I understand this DisableIoMapperMapping explanation... It appears to say that the quirk must be enabled to resolve compatibility issues where the native DMAR table contains one or more Reserved Memory Regions at the same time that the quirk requires a native DMAR table that does not contain Reserved Memory Regions.  What am I missing?  Thank you.

[FirstCustomac]

I read it as, for macOS 13.3+, this quirk may be required to fix compatibility issue with Wi-Fi, Ethernet when AppleVTD is enabled. This applies to

 

1. Systems with native DMAR table that contains no reserved memory region.

2. Systems with native DMAR table that contains one or more reserved memory regions that required a patched DMAR table to fix Wi-Fi, Ethernet compatibility issue prior to macOS 13.3 

 

I guess it's saying in the end, whether it's native or modified, if your system is affected, you need a DMAR table that contains no reserved memory regions.

Edited December 8, 2025 by FirstCustomac

[deeveedee]

@FirstCustomac Thanks!  I think I'm going to need to read it a few more times to reach that same interpretation.

[arsradu]

11 hours ago, deeveedee said:

 

Not sure I understand this DisableIoMapperMapping explanation... It appears to say that the quirk must be enabled to resolve compatibility issues where the native DMAR table contains one or more Reserved Memory Regions at the same time that the quirk requires a native DMAR table that does not contain Reserved Memory Regions.  What am I missing?  Thank you.

 

There might be a missing word somewhere inside Note 1.  Something like: "does not contain patched Reserved Memory Regions ".
So, probably something like this would make more sense in the context: "requires native DMAR table where Reserved Memory Regions haven't been patched, or removed with a SSDT-DMAR.aml"

 

I think it was just meant to say that DMAR needs to be "native/untouched". Just my opinion, of course. I could be wrong. But yeah, I understand why it could be confusing.

Edited December 8, 2025 by arsradu

[Mieze]

Here is build 3.0.4, which eliminates a weakness in the buffer allocation code of prior versions. Have fun!

 

Mieze 😺

RealtekRTL8111-V3.0.0-build-3.0.4.zip

[mengshi]

I am using this driver. I also use OCAuxillary tool. I notice that the Update kext feature of OCAT does not update this kext to the latest version. Why is that?

[kaoskinkae]

I'm a bit of a stickler for kexts and their usage depending on the system, although I only have the latest system installed (Tahoe on an SSD and Tahoe beta on an NVMe). My question is, from version 2.5.0 up to the new unofficial 3.0.4, which "MinKernel" would be correct: 15.0.0 or 23.0.0?

[Slice]

For me 3.0.4 works both in Sequoia and in Tahoe. So minkernel can be 15.0.0

[MacKonsti]

On 12/14/2025 at 3:04 PM, Mieze said:

Here is build 3.0.4, which eliminates a weakness in the buffer allocation code of prior versions. Have fun!

Hello @Mieze is this the same driver as the one published in your GitHub? i.e. v3.0.4? Thank you

[Mieze]

Yes, the official releases are the latest builds. A few days before Christmas I packaged the latest build for all drivers to publish them as official releases here in the download section and as releases on GitHub.

 

Mieze 😺

[kaoskinkae]

I've been using the betas available here, RealtekRTL8111-V3.0.0-build-3.0.3.4. But especially in Chrome, there's a considerable delay when selecting a URL and returning to the Chrome search homepage. Sometimes I have to close Chrome completely before I can use it properly.

[Mieze]

@kaoskinkae What makes you assume that it has anything to do with the driver?

 

Mieze 😺

[mengshi]

The latest driver V3 does not automatically get. updated by OCAT. The settings points to Dortania GitHub (https://dortania.github.io/builds/?product=RealtekRTL8111&viewall=true). It is still 2.4.2 there.

[Slice]

I encountered a strange situation:

1. Booted as MacPro7,1 I loose internet. Reboot - the same.

2. Reboot as iMac20,1 I got all working

Tahoe 26.5.2. Realtek8111H

Why it may happens?

[deeveedee]

@Slice I know you're a big fan of AI 🤣 .... Seriously, though - this might be a good question for ChatGPT.  Some of the response doesn't make sense, but some of may offer a clue.

 

If you're running a Hackintosh/OpenCore on macOS Tahoe 26.5.2 and the only variable is the SMBIOS (MacPro7,1 vs iMac20,1), then the Realtek controller itself is probably not the root cause. The SMBIOS changes how macOS configures several networking and security features.

Here are the most likely explanations, roughly in order of probability:

1. Ethernet interface gets recreated or renamed

- Booting with a different SMBIOS can cause macOS to treat the NIC as a different device.
- Check:

ifconfig

networksetup -listallhardwareports

- See whether the Ethernet interface is still en0 or became en1, or disappeared entirely.

2. Ethernet driver initialization timing

- If you're using RealtekRTL8111.kext (Mieze) or LucyRTL8125Ethernet.kext, initialization timing may differ between SMBIOSes.
- Look in:

log show --last boot | grep -i RTL

log show --last boot | grep -i ethernet

- Also verify that the driver actually attached:

kextstat | grep RTL

or on newer macOS:

kmutil showloaded | grep RTL

3. Different DeviceProperties or ACPI paths

- Some OpenCore configurations inject properties conditionally depending on SMBIOS.
- Compare:
    - DeviceProperties
    - ACPI patches
    - Kernel -> Add
- Make sure nothing is enabled only for iMac20,1.

4. Network service order corruption

macOS stores network configuration separately.

Try backing up and deleting:

/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
/Library/Preferences/SystemConfiguration/preferences.plist

Then reboot so macOS recreates them.

5. MacPro7,1-specific networking behavior

MacPro7,1 expects workstation-class hardware and may enable features not present on consumer boards.

Rarely this affects:
- Wake-on-LAN
- Energy Efficient Ethernet
- PCIe ASPM

A Realtek driver may not handle one of these correctly.

6. Different kernel cache or loaded extensions

Verify that exactly the same kexts are loaded under both SMBIOSes:

kmutil showloaded

Compare the output between MacPro7,1 and iMac20,1.

--------------------------------------------------
Information that would be most useful
--------------------------------------------------

Boot using MacPro7,1 (where networking fails) and run:

ifconfig

networksetup -listallhardwareports

kmutil showloaded | grep -i rtl

log show --last boot --predicate 'subsystem CONTAINS "network"' --style compact

or simply:

log show --last boot | grep -i RTL

Also provide:

- Which Ethernet kext are you using?
    - RealtekRTL8111.kext?
    - LucyRTL8125Ethernet.kext?
    - Something else?

- OpenCore version.

- Motherboard model.

- Does the Ethernet interface appear but have no IP address?
- Or is the Ethernet interface completely missing?

One additional question:

When you say "lose internet," which of these best describes the problem?

1. The Ethernet interface is missing.
2. The Ethernet cable shows as unplugged.
3. Ethernet connects and gets an IP address, but nothing can reach the Internet.
4. Local network works but DNS or web browsing fails.

That distinction will narrow the cause significantly.
One thing I'd add based on experience with recent Hackintosh setups: if the only change is SMBIOS and the problem is 100% reproducible, I'd also compare the IORegistry between the two boots (IORegistryExplorer or ioreg -l) to see whether the Realtek PCI device receives different properties. That's one of the quickest ways to determine whether the issue lies in OpenCore's device injection versus the network driver itself.

 

Edited 54 minutes ago by deeveedee

[Mieze]

@Slice The network configuration is bound to the system definition in the same way, as the USB port mapping.