IntelMausiEthernet.kext for Intel onboard LAN

[schrup21]

19 hours ago, Mieze said:

IntelMausiEthernet, which supports AppleVTD under Tahoe 69.34 kB · 24 downloads

Confirmed, works with AppleVTD enabled (and BCMC WiFi) - big thanks! 😊 

[Mieze]

Attached you'll find the next update, version 3.0.0 build 3.0.3, which fixes a minor bug I had found during continued testing and code review. Have fun!

 

Mieze 😺

IntelMausiEthernet-V3.0.0-build-3.0.3.zip

[Henties]

@Mieze Thanks, just wandering whether you plan to apply tour VTD magic also to your LucyRTL8125Ethernet.kext V 2.2.2 which I am presently running on my Alder Lake hack, the one you helped me with many moons ago. 

 

With that kext also done the path would be paved to apply the patches, without OCLP, to get wifi as well as audio working on Alder Lake.

 

I can use OCLP 2.4.1 on Sequoia but I cannot apply OCLP 3.0.0 (nightly) to Tahoe 26.2. As soon as I enable IOSkywalkFamily.kext in the config.plist with MaxKernel 25.99.99,  so that it also applies to Tahoe, the hack just reboots immediately after the Tahoe boot selection has been initiated and the boot progress bar appears.

 

The boot text messages fly past so fast that I have as yet not been able to more or less catch the position which may initiate the hack to reboot.

 

All this is happening even when there is no OCLP whatsoever installed on Tahoe.

 

Booting Sequoia without OCLP present does not suffer this phenomena even with all the kexts required for root patching being active, the kexts just merrily ride along as passengers.

 

For Tahoe AMFIPass.kext is, as required, disabled with the boot arg. amfi=0x80 being used.

 

Would appreciate your opinion on this one.

 

Greetings Henties  

Edited December 15, 2025 by Henties

[deeveedee]

@Mieze With IntelMausiEthernet.kext 3.0.3, my HP EliteDesk 800 G4 Mini has full Ethernet connectivity in Tahoe 26.2 with VT-d enabled in BIOS and Kernel > Quirks > DisableIoMapper = False.  The original system DMAR table is untouched.  I've only just started testing, but your latest build looks awesome!

 

Thank you!

 

Edited December 15, 2025 by deeveedee

[Mieze]

@Henties LucyRTL8125Ethernet.kext will be replaced with a new project, which won't be based on Realtek's own linux driver source code but on the corresponding driver of the official Linux kernel. Unlike Realtek's code, this one separates the firmware from the code making it possible to update the firmware and support new family members without having to rewrite about 50% of the code. It will also allow to add support for the RTL8126 (5Gbit/s) and the RTL8127 (10Gbit/s). Unfortunately, it will take at least 2 weeks of full time work to get the new driver up and running and I still haven't found the time for that because I've been busy with other projects.

 

Mieze 😺

[Henties]

@MiezeGreat news indeed, thanks for attending to that one as soon as your time permits, patience costs nothing I have ample of that too.

 

Greetings Henties

 

[MacKonsti]

Hello @Mieze from me too, together with my warm thanks for your continued effort despite Apple dropping Intel soon, as well as my season greetings, a quick question:

If I replace my existing IntelMausi v1.0.8 (Release) from the Acidanthera repo, with your latest v3.0.3 from here, do you know or suspect if I need to do any re-configuration of the network (or delete /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist) or would the swap of the kext will be seamless to the OS?

I am still running Sonoma and won't move an inch towards Tahoe, it's @deeveedee who's the adventurer 😂

P.S. I have subscribed to notifications of your Github repos and it wasn't updated with your great work yet!

Thank you again--wish you a great festive season.

[Mieze]

@MacKonsti Thanks for your kind words❣️ Exchanging the kext shouldn't require any reconfiguration.

 

Mieze 😺

[Slice]

I can confirm that  IntelMausiEthernet.kext 3.0.3 works in Sequoia with or without VT-d. But I have a problem in Tahoe that the kext is not working while 2.5.4 works with VT-d off.

May be this is only for me.

[Mieze]

@Slice Disable SIP and install to /L/E/ in order to get log data. Even the release build produces error messages. If more detailed log data is required, you need to  use a debug build.

 

Mieze 😺

[Slice]

On 12/22/2025 at 5:30 PM, Mieze said:

@Slice Disable SIP and install to /L/E/ in order to get log data. Even the release build produces error messages. If more detailed log data is required, you need to  use a debug build.

 

Mieze 😺

There is the kernel log related to the kext 3.0.3.

LAN is ON for one seconds, then OFF then again ON and so on.

log_Mausi.txt

[deeveedee]

@Slice are you patching DMAR?  I don't know if that's an important detail to report with your IntelMausiEthernet test results.

[Mieze]

@Slice Your kernel logs look normal. There is nothing unusual in it. You might want to try the following things:

• Patch your DMAR, but I assume you already did that?
• Set DisableIoMapperMapping to true as suggested by @arsradu (Thank you for pointing out this workaround!).

If this doesn't help, there is nothing more I can do for you. After all, it boils down to the sad fact that there are some mainboards which aren't compatible with AppleVTD. I hope your's isn't one of those. 

 

Mieze 😿

[arsradu]

1 hour ago, Mieze said:

 

• Set DisableIoMapperMapping to true as suggested by @arsradu (Thank you for pointing out this workaround!).

Yep, that seems to help quite a lot in my case. The only issues I still have, and it seems those too are caused by AppleVTD, are connections to my work VPN for example (probably others too). Same issue. It suddenly disconnects and reconnects. Doesn't seem to be disconnecting anymore in Settings > Network. But yeah, third party softwares seem to be taking a hit, still. So...either OC needs an update somewhere...to improve this patch, or there's just no way to fix that 100% and keep VTD enabled. There are no such issues with VTD disabled (completely). So DisableIOMapper set to True. But yeah, definitely some challenges here and there.

Edited December 31, 2025 by arsradu

[J Lamp]

On 12/22/2025 at 8:12 AM, Slice said:

I can confirm that  IntelMausiEthernet.kext 3.0.3 works in Sequoia with or without VT-d. But I have a problem in Tahoe that the kext is not working while 2.5.4 works with VT-d off.

May be this is only for me.

Nope, not just you @Slice

 

Precisely the same issue with my x299. Thankfully the board also has an i211 chip for the second network port, which is apparently natively supported for the last couple OS revisions. I don't know what the current status is with the AQC107, but a few versions back I had to patch DMAR and enable VT-D to get that working. Based on the fact that this has been great up till Tahoe I think that something else is at fault (not hardware.) That in no way implies any finger pointing at the fine and generous developers who have made all this possible over the years.

 

In a cynical way I wondered if Apple would throw a wrench in the works to push clients into buying new computers. Though I have been using this rig for years, dual booting Mac and Windows (again thanks to everyone here,)  I've never had the stability issues I have had since switching to Tahoe. Logic crashes constantly, I've seen this complaint elsewhere from mac users, even on Apple Silicon.

 

My two cents, I switched out my RX6600 back to my trusty RX580, I've reinstalled Sonoma for music production, fired up an old Mojave backup for photo editing (Adobe CS6) and still have Windows for the day job (yuk.) Everything is back to fully functional and rock solid, including @Mieze 's IntelMausiEthernet.kext.

 

 

[Slice]

On 12/31/2025 at 3:10 PM, Mieze said:

@Slice Your kernel logs look normal. There is nothing unusual in it. You might want to try the following things:

• Patch your DMAR, but I assume you already did that?
• Set DisableIoMapperMapping to true as suggested by @arsradu (Thank you for pointing out this workaround!).

If this doesn't help, there is nothing more I can do for you. After all, it boils down to the sad fact that there are some mainboards which aren't compatible with AppleVTD. I hope your's isn't one of those. 

 

Mieze 😿

Sorry, I have no more this hackintosh so I can't check more.

DMAR is no matter as I check with and without VT-d switching on and off in BIOS.

The key problem that the kext is working in Sequoia and not in Tahoe.

[Modmike]

I just stumbled on this. Running Asus Z390-I on open core 1.0.7. What's the advantage of this IntelMausiEthernet.kext over the one from the opencore team? Maybe put the answer post #1.

[deeveedee]

@Modmike The changelog is in Post #1.  At the time of this post, use the 3.0.3 build posted here.  Start reading here for advantages over the Acidanthera build.

[deeveedee]

Since macOS 26.2, I have not observed any issues when using IntelMausiEthernet.kext 3.0.3 with VT-d enabled in BIOS and Kernel > Quirks > DisableIoMapper = False.  After upgrading to Tahoe 26.4 Release (25E246), I am finding that Ethernet may not be connected when I boot macOS.  I can fix the Ethernet connection by either disconnecting/reconnecting the Ethernet cable or disabling/enabling Ethernet (ifconfig en0 down; ifconfig en0 up).

 

It appears that I can also fix this problem by setting Kernel > Quirks > DisableIoMapper = True, but I'm still testing to confirm that this is consistent.

 

I'm still testing, since other things that I did at the time of the macOS upgrade included

• Upgrade Open Core from 1.0.6 -> 1.0.7
• Upgrade AppleALC.kext 1.9.6 -> 1.9.7 (don't see why this would matter)

 

Has anyone else observed this change in behavior of IntelMausiEthernet.kext 3.0.3 after upgrading to Tahoe 26.4 Release?

Edited March 28 by deeveedee

[Mieze]

@deeveedee After booting with 26.4 and IntelMausiEthernet.kext please check in Terminal using ifconfig:

• Is the link up?
• Has the interface received an IPv4 address via DHCP?
• Hast the interface received an IPv6 Address?

[carlo_67]

if it can be helpful here no problem, thanks👍

 

 

[deeveedee]

@Mieze Thank you for the quick reply!  I am ok with setting Kernel > Quirks > DisableIoMapper = True and am only providing this information in case it helps you or anyone else.

I performed 10 boot tests with results below.  5 tests with Kernel > Quirks > DisableIoMapper = True and 5 tests with Kernel > Quirks > DisableIoMapper = False.  My test configuration is as follows:

• BIOS: VT-d enabled
• EFI:
  • Open Core 1.0.7
  • Original System DMAR Table is not modified
  • IntelMausiEthernet.kext 3.0.3

Test results are as follows:

 

With Kernel > Quirks > DisableIoMapper = True

• For each of the 5 boots, Ethernet is always connected with assigned IPv4 after boot and with full access to internet

 

With Kernel > Quirks > DisableIoMapper = False

• For 1 of the 5 boots, Ethernet is connected with IPv4 IP assigned after boot - full access to internet.
  Spoiler

  

   

• For 2 of the 5 boots, Ethernet IPv4 is "self-assigned" - no access to internet.  Toggling Ethernet with attached script fixes internet connection.
  Spoiler

  

• For 2 of the 5 boots, Ethernet is not connected with no IPv4 assigned - no access to internet. Toggling Ethernet with attached script fixes internet connection.
  Spoiler

  

 

 

EDIT: I am not using IPv6.

toggleEth.zip

Edited March 28 by deeveedee

[Mieze]

@deeveedee Please check in Terminal because the network preferences panel often shows a not connected sign when the interface has no IP address, although the link is up.

[deeveedee]

@Mieze My apologies for the delay.  I'm away from my EliteDesk 800 G4 Mini now, but will provide diagnostics from terminal when I get back to it.

[Mieze]

@deeveedee No need to hurry. Take your time!

 

Mieze 😺