New Driver for Realtek RTL8111

[ZHIDR MI]

50 minutes ago, verdazil said:

@ZHIDR MI，RealtekRTL8111.kext kext 和 AppleVTD 驱动程序彼此之间没有直接关系，但在某些情况下它们会相互影响系统的稳定性。

 

I have disabled VT-D, but I still can't find the network card.

[Mieze]

I have explained it over and over again and it looks like I have to explain it one more time! Version 2.5.0 was created to make the driver compatible with AppleVTD because certain technologies like WLAN and Thunderbolt require the use of AppleVTD. It is in no way unstable, provided it is used properly. Please read the instructions before making false claims that RealtekRTL8111. kext and AppleVTD don't affect each other, because when AppleVTD is enabled, the IOMMU is used when talking to PCIe devices.

[Mieze]

@ZHIDR MI As you are using Wifi, you have to keep AppleVTD enabled and install 2.5.0. According to your IOReg, the driver is loaded but seems to have failed to initialise the hardware.

[ZHIDR MI]

On 2025/5/15 at AM1点13分, Mieze said:

@ZHIDR MI 由于您使用的是 Wifi，因此必须保持 AppleVTD 启用并安装 2.5.0。根据您的 IOReg，驱动程序已加载，但似乎未能初始化硬件。

I turned on VT-D, but it didn't work.

vtd.ioreg

[Mieze]

@ZHIDR MI According to your IOReg dump, the NIC doesn't have an Interrupt assigned to it so that the driver can't work. It should have an IOInterruptControllers and IOInterruptSpecifiers property telling the driver which interrupt to use, but there is none. See screenshot below. This is either due to a wrong UEFI setup or an error in the ACPI data structures. In oder to make the driver work, you have to fix this problem.

[Max.1974]

THX 

[ZHIDR MI]

11 hours ago, Mieze said:

@ZHIDR MI 根据您的 IOReg 转储，网卡没有分配中断，因此驱动程序无法工作。它应该有一个 IOInterruptControllers 和 IOInterruptSpecifiers 属性来告诉驱动程序应该使用哪个中断，但实际上没有。请参见下面的屏幕截图。这可能是由于 UEFI 设置错误或 ACPI 数据结构错误造成的。为了使驱动程序正常工作，您必须修复此问题。

I can upload the relevant files, could you please help me solve this problem?

[deeveedee]

On 2/14/2025 at 3:49 PM, Mieze said:

@daemon17 As already mentioned before, the driver is now compatible with AppleVTD but this doesn't mean that the mainboard also is! If your mainboard is not compatible with AppleVTD and patching the DMAR doesn't help, there is no way to make it work with AppleVTD and you'll have to keep it disabled.

 

Sorry for the OT post.  Just wanted to let you know that when VT-d is enabled in BIOS, I need to set Kernel > Quirks > DisableIoMapper to true (Open Core 1.0.5 Beta) for working IntelMausi.kext in macOS Tahoe Beta 1.  Prior to Tahoe Beta 1, IntelMausi.kext works fine with Kernel > Quirks > DisableIoMapper = false (and VT-d enabled in BIOS).  Could it be that a similar driver change is needed for IntelMausi.kext?  My Ethernet is Intel I219LM Gigabit Ethernet in this HP EliteDesk 800 G4 Mini.

 

Credit to @lorys89 for his solution to a related issue here.

 

My full system specs:

• Ethernet: Intel I219LM Gigabit Ethernet
• Chipset: Q370
• macOS: Tahoe Beta 1

[kaoskinkae]

I disabled the AppleVTD issue. I had it up and running with version 2.5.0 of the kext in question, but for the connection to work, I had to manually configure this if I managed to connect via cable. Now, due to a fenvi activation method that didn't work, I reactivated AppleVTD, but in this case, even with the manual connection, I couldn't. Curiously, to be able to do it manually, I had to do it before activating AppleVTD.

Is there a solution to this issue or a kext? I've tried several ways to activate AppleVTD. With or without the DSDT-DMAR.aml, with or without the "CaseySJ-macOS-Ventura-AppleVTD-Patch.plist" patch.
In all cases, no connection was made with kext 2.5.0.

[Mieze]

I tested the driver with Tahoe during the last days and can confirm that it works with 26.0 and 26.0.1, but AppleVTD support is broken. Unfortunately there is no easy solution for this problem, so that you'll have to keep AppleVTD disabled while using the driver with Tahoe. I hope to get more information once the source code of Tahoe is out. My investigation of the problem indicates that DMA buffer mapping by the IOMMU has to be reworked, which isn't an easy task and might require some to time to find a convenient solution.

 

Mieze

[mnfesq]

I have an Asus Chromebox 3 CN65 with an i7-8550U processor that I converted to a Macmini8,1.  It uses the Realtek RTL8111 driver but I have been plagued with a problem that defies explanation.  For whatever reason, the driver is unable to detect the MAC address for the LAN device and that results in a self-assigned IP address and no function.  Manually adding an IP address and DNS does not fix the problem.  After hours of scouring the internet, I found something that suggested using the fallbackMACaddress which is found in the info.plist for the RTL8111 kext.  The problem is that I had no way of finding out what the MAC address was for the LAN device because it showed up as 00:00:00:00:00:00.  Instead of installing windows on the computer or running something equivalent to a Windows Live disk, I continued to scour the internet until I saw the suggestion of just using random numbers and putting them into the correct format (six 2-digit numbers separated by colons).  I decided, instead, to use the MAC address from an old WiFi chip I had lying around and added that to the info.plist.  It worked perfectly. While I had working WiFi on the computer, the speed is so much faster when I connect the ethernet cable so it's perfect for downloading large updates and for video broadcasting in 1080p.

 

The fallbackMACaddress is a great feature of the RTL8111 kext and should not be forgotten even if most of us don't need to use it.

Edited October 16, 2025 by mnfesq

[Mieze]

As promised a few days ago, here is version 3.0.0 of RealtekRTL8111.kext which adds support for AppleVTD under Tahoe. As usual, the source code can be found on GitHub. Have fun and good luck testing!

 

Mieze 😺

RealtekRTL8111-V3.0.0.zip

[Henties]

@Mieze, thanks for your new RealtekRTL8111 version 3.0 kext which is "immune" to whatever AppleVTD is configured.

 

I tried to use it on an Alder Lake hack as a direct replacement for your RealtekRTL8111 version 2.4.2 kext as well as on a Comet Lake hack also as a direct replacement for your RealtekRTTL8111 version 2.5.0 kext.

In both cases the new kext failed to initialize D-Link DGE 560T PCIe addon NICS, therefore I had to revert back to the originally used kexts in order not to loose networking altogether.

 

Will continue testing on another hack to ascertain if I can get it working there, which by the way is also Comet Lake based.

 

I naturally followed the usual proven procedure, "resetting Nvram", when I conducted my experiments with your latest kext.

 

Greetings Henties  

 

Edit 1:

Did a complete re-config of the network port whereafter I get the following as per the attached pictures:

Note the port is now activated but without a mac address.  This was on Alder Lake, will test the Comet Lake hacks as well.

 

Edit 2:

Can confirm that Sequoia yields the same results as depicted by the screenshots taken under control of Thahoe with the mac address placeholder remaining unpopulated, resulting in a non functioning network port.

 

Edited December 2, 2025 by Henties

[Mieze]

@Henties Please send me an IOReg dump. Deleting the network preferences helps to resolve some strange error, but I guess you already did that?

sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

It's a well known problem, that on certain strange adapters the driver fails to retrieve the permanent MAC address. The reason for this failure is unknown and I haven't been able to reproduce such a scenario. Therefore I added the fallbackMAC property to the driver's Info.plist, where you can supply a MAC address as a workaround. Besides that, I haven't changed the hardware initialisation code since 2.4.2, so that I see no reason why this should happen with the new version?

 

Mieze 😺

[Henties]

@Mieze thanks for your feedback. Have done some extensive testing all day long and will send you ioreg dumps as soon as I am back at the Alder Lake hack.

 

I normally delete the /Library/System Configuration folder in its entirety and start from scratch with networking configuration. This method seems to provide me with better control as to which en[0,1,2] is occupied by which NIC. I like to keep this uniform throughout all the opsyses that a particular hack is servicing.

 

The onboard NIC, of the Alder Lake hack, being a Realtek 2.5 GbE, for which I use your LucyRTL8125Ethernet.kext version 1.2.2, works great but it will just not allow either the RealtekRTL8111.kext version 2.5 or version 3.0.0 (VTD) to work at all. Both can however sort of be configured with the mac address placeholder remaining empty.

 

The RealtekRTL8111.kext version 2.4.2 does not have this shortcoming, working perfectly in all respects, even when the Realtek 2.5 GbE is active.

 

I will send you a Tahoe registry dump as soon as I am finished here in Sequoia and have booted back into Tahoe.

 

It might be noteworthy that am not using any macOS beta versions. 

 

Greetings Henties

 

 

Mainbrain Sequoia 15.7.2 (24G325).ioreg

Edited December 2, 2025 by Henties

[Henties]

@Mieze Had to open another posting because of size constraints.

 

Attached find the registry dump for mainbrain Tahoe 26.1 (25B78) on Alder Lake

 

I also made some interesting discoveries whilst testing your new RealtekRTL8111.kext version 3.0.0 (VTD) on my

 

2 Comet Lake hacks, will summarize my findings once you had an opportunity to dig into the Alder Lake related

problems, not wishing to confuse the issues at this early stage of troubleshooting.

 

Greetings Henties

mainbrain Tahoe 26.1 (25B78).ioreg

[Henties]

@Mieze previously I forgot to mention that the 2 registry dumps were taken with your RealtekRTL8111.kext version 2.4.2 active because I had already restored the system to a known and working situation using this particular kext of yours.

 

Greetings Henties 

[Mieze]

@Henties I need the dump with 3.0.0 to find out what is going on.

[Henties]

@MiezeI realized that after shortly posting yesterday. 

Will be sending you that/those dumps soonest.

 

Greetings Henties

[Henties]

@Mieze Here we go, with the Alder Lake Tahoe 26.1 (25B78) registry dump using your 

RealtekRTL8111.kext Version 3.0.0 

Also included a screenshot showing the output of ifconfig.

         en0 depicts the output for the Realtek 2.5 GbE onboard NIC under control of AppleIGC.kext Version 1.7

         en1 depicts the output of your RealtekRTL8111.kext Version 3.0.0 

 

Also included are 2 screenshots taken in the System Settings Network area.

        the first one depicts that the DGE-560T-VTD add on NIC is connected.

        The second one depicts that the MAC address placeholder for the DGE-560T-VTD NIC is unpopulated.

 

Finally I have included a screenshot depicting the settings of the Kernel --> Quirk section.

 

Please note that I cannot set "DisableIoMapper" --> NO as that would remove the networking functionality of 

this hack because the onboard Realtek 2.5 GbE NIC depends on it being set to YES.

 

Please let me know what else you may require in order to get to the bottom of this anomaly.

 

Greetings Henties

 

Oh just on the side, your RealtekRTL8111.kext Version 3.0.0, on my Comet Lake hack, which has a compatible

Fenvi T919 wifi card installed, works like a charm, therefore one can perhaps assume that the problem with the Alder Lake hack is platform related and NOT related to your kext.

 

A special thanks and gratitude for the effort and time you are investing in rectifying the problems.

  

mainbrain Alder Lake Tahoe 26.1 (25B78) .ioreg

[arsradu]

Hey guys,

 

Quick question: are you guys using WiFi + Ethernet with this driver (version 3.0.0 in my case)? I'm not sure which side is having issues here but, when WiFi is enabled, Ethernet keeps disconnecting and reconnecting. Like I can see it being disabled in System Settings > Network and then coming back up. With WiFi disabled, I don't seem to have this issue. Looks like some sort of conflict here.

WiFi alone seems to be working fine (using Austere's AppleBCMCCompanion kext), Ethernet alone seems to be working fine. Together...not so much.

 

update: apparently it disconnects even without WiFi...just not as often.

MacOS: 26.1. VT-D enabled.

Edited December 4, 2025 by arsradu

[Mieze]

@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 😺

Edited December 4, 2025 by Mieze

[Mieze]

@Henties Frankly, I don't understand why you haven't solved the problem yourself by adding the fallback MAC to the driver's Info.plist. This feature has been added to cope with situations, in which the driver is unable to retrieve the adapters permanent MAC address. Anyway, I'm going to modify the driver to generate a random MAC as a last resort in such scenarios, so that a working interface can be achieved even without the fallback MAC.

 

PS: Attached you'll find a new version which generates the random MAC address.

 

Mieze 😺

RealtekRTL8111-V3.0.1.zip

Edited December 4, 2025 by Mieze

[Henties]

@Mieze I was frankly not aware that one can actually add a fallback MAC to the drivers info.plist.

 

Will investigate to try and figure this out by myself and also try your V3.0.1 kext at the next best opportunity.

 

Thanks a stack for your feedback and support.

 

Greetings Henties

[Henties]

@Mieze found the fallbackMAC placeholder in your info.plist for this kext. It is even present in Version 2.4.2 as well as Version 2.5 of this kext.

 

Guess one only needs to plugin a MAC address in the format "78:98:e8:c1:7c:20" into the fallbackMAC string placeholder of the info.plist and voila the problems are gone. Please confirm that my assumption as well as the format is correct.

 

Will try this tomorrow after I had a few minutes sleep.

 

My networking activities depend on the MAC addresses of the NICs active in my network therefore, in this particular instance, I just plugin the correct MAC address that was assigned to the NIC by the manufacturer and all should be golden.

 

Greetings Henties.