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.