Contribute
Register

[GUIDE] Replace non-working Intel I225 with 82574L PCIe NIC (Monterey + OpenCore)

The simplified method - Buy a real Mac!

What are you trying to do, install and setup a new PCIe Network card? Which card? Which version of macOS are you running, Monterey?

Your motherboard has 2 x Ethernet ports, do neither work? I would expect you to have issues with the 2.5GB Ethernet port, but you should be able to get the 1GB port working, if you have Acidanthera's IntelMausi.kext in your setup.
 
sorry for the misunderstanding , i wasn't talking about the hardware on my profile, i was talking in general, pretty much on how to have native Ethernet without needing a kext, I have most of the Ethernet cards supported in mac with their respective IDs im only missing this one card the 82574L , I was merely asking how to flash the vendor ID in a more simplified way, im not a Pro at hackintosh, but im trying to get right IDs from pcie cards widely and cheaply available without having to use an extra kext, so far i have identified at least 4 cards that matches the id number, all of this is probably irrelevant, as most if not all cards work with the available kexts, im just trying to have Ethernet working natively, im sure im just wasting my time on this, nobody will spend money on a pcie card when a simple kext will do just fine with the onboard LAN, while this may sound just plain dumb, i have managed to properly identify the right cards with matching IDs in apples kexts im just missing this one, like this guide suggest , it seems to be a simple process, i have access to a full linux machine but still cant understand how to flash the id to 10F6
 
I have no idea how to flash the device id in Linux. As that is not what this thread is about.

This thread is about using an alternative Ethernet card in macOS, using third-party and native Apple Ethernet kexts. But making sure the 'Alternative' card is registered as 'built-in', which macOS relies on for getting Apple Services such as Messages, iCloud etc. working at their best.
 
Background

With the release of MacOS Monterey, many of us with motherboards that have an on-board Intel I225 NIC have found that it is no longer functional, despite the fact it was working well in MacOS BigSur.

There have been many attempts to resolve the issue using different approaches but so far there is no clear answer. It is speculated that the problem could be something to do with the hardware revision and/or firmware version of the I225 chip, however this is still un-proven and the recommended solution in 95% of cases is to disable the on-board I225 NIC and replace it with an alternative.

Many users have had success using a cheap USB->Ethernet adapter, however almost all USB->Ethernet adapters use software running on the CPU to process the LAN packets rather than processing them on the bare metal NIC. As a result these adapters only provide basic connectivity and are not capable of running in promiscuous mode and most lack support for more advanced features such as Wake on LAN.

There are number of PCIe NiC's that can be made to work on MacOS Monterey using 3rd party kexts that have been developed by the Hackintosh community such as Intel cards supported by the IntelMausi kext which is now maintained by Acidanthera and RealTek based cards using the kext's maintained by Mieze.

Another approach is to inject older kext's to support Ethernet NIC's that Apple long dropped support for, however this approach is not something I would personally recommend as Apple could depreciate the API's that these kexts rely on at any time.

I was not really interested in any of the above approaches and wanted to see if it was possible to use a current and natively supported PCIe NIC in Monterey, one that uses Apple supplied and maintained kexts rather than one relying on a 3rd party or depreciated kext.

It should be noted that Apple have removed official support for many 3rd party NIC's in MacOS Monterey that where once supported in BigSur and earlier versions of MacOS so the options are now somewhat limited and official documentation on what PCIe NIC's are supported is hard to find.

So the first thing I did was to take a peek in IONetworkingFamily.kext/Contents/Plugins which is located in the /System/Library/Extensions folder, here we can see the following natively supported kext drivers for Ethernet NIC's.

View attachment 542457
From the above list I was able to research the capabilities of each supported NIC's and as my local LAN is 1 Gigabit Ethernet I decided to go with an Intel 82574L based solution as these cards are cheep and wildly available and only require a PCIe x1 expansion slot. After a quick search on my preferred hardware suppliers web store I found the following PCIe card :-

Intel Gigabit Pro 1000CT PCI Express Gigabit Network Card OEM
View attachment 542462
1 Port Intel Gigabit PRO EXPI9301CTBLK 1000CT Gigabit PCI-e Network Adapter - OEM

As MacOS Monterey has a kext driver specifically for the Intel 82574L NIC I was somewhat hopefully that VID & PID would match the ones defined in Apples kext and it would esentially be plug and play, however this proved not to be the case.

After some experimentation I found the solution was to modify the device properties of the NIC, make a small patch for the kext and then force MacOS to load the kext during boot-up.

Rather than just give you the code to cut and paste i'll try to explain what each part of the fix does and why it is needed, that said if your not familiar with OpenCore I highly recommend reading the official documentation and referencing the sample config.plist, both can be found in the Docs folder that is included with each release of OpenCore.

The following method should work for any motherboard and will most likely work for any of the Ethernet kext drivers in IONetworkingFamily.kext/Contents/Plugins with modification to the file paths, identifiers and PID's/VID's.

For reference I'm booting MacOS Monterey 12.2.1 via OpenCore 0.7.8 on a Gigabyte Z490 Vision G.

Prerequisites

First, backup your existing EFI folder, so that you have working EFI that you can fall back to if things go wrong.

Next you should remove any existing kexts, device properties and boot args from your OpenCore EFI and config.plist that you may have been using for the Intel I225, once you have made and saved the changes, shutdown the system and install the new PCIe card in a empty PCIe slot. As the Intel 82574L PCIe card only has a PCIe x1 interface I recommend installing it in one of the PCIe x1 slots that is routed through the PCH, since the built in Intel I225 NIC was also routed through the PCH it should not put any extra load on the PCH data bus.

Note that installing a Ethernet PCIe card in one of the expansion slots that is directly connected the CPU will reduce the number of PCIe lanes available for a dGPU (if you have one installed).

Once you have installed the new PCIe Ethernet card, boot up the PC and enter the BIOS to disable the on-board Intel I225 Ethernet NIC.

View attachment 542601

Save the changes, and boot into MacOS Monterey normally.

Step-1 - Identify the Intel 82574L NIC's Device Path.

Run HackinTool and click on the PCI icon and find the new Intel 82574L NIC in the device list, right click on the entry for the Intel 82574L NIC and select "Copy Device Path"

View attachment 542463

In my case the Device Path for the Intel 82574L NIC is PciRoot(0x0)/Pci(0x1B,0x2)/Pci(0x0,0x0) but this will be different depending on the make/type of motherboard you have and PCIe slot you put the card in.

Step-2 - Create Custom Device Properties for the Intel 82574L NIC

Mount your EFI partition and open your OpenCore config.plist in the editor of your choice, I always work with the raw code using BBEdit, but you can use whatever code or plist editor you want.

Using the Device Path you copied from Hackintool, create a new <key> in the DeviceProperties->Add section of your config.plist.

Code:
    <key>DeviceProperties</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>PciRoot(0x0)/Pci(0x1B,0x2)/Pci(0x0,0x0)</key>

Now copy and paste the following device properties after the <key> you just created.

Code:
            <dict>
                <key>AAPL,slot-name</key>
                <string>PCIEX4</string>
                <key>built-in</key>
                <data>AA==</data>
                <key>device-id</key>
                <data>9hAAAA==</data>
                <key>device_type</key>
                <string>Ethernet Controller</string>
                <key>subsystem-id</key>
                <data>AAAAAA==</data>
                <key>subsystem-vendor-id</key>
                <data>AAAAAA==</data>
                <key>vendor-id</key>
                <data>hoAAAA==</data>
            </dict>

Change the string value for AAPL,slot-name to match the slot you have installed the Intel 82574L NIC in, in most cases you will likely have other existing entires but for this example I will keep it simple so the Device Properties section it should now look something like this :-

Code:
    <key>DeviceProperties</key>
    <dict>
        <key>Add</key>
        <dict>
            <key>PciRoot(0x0)/Pci(0x1B,0x2)/Pci(0x0,0x0)</key>
            <dict>
                <key>AAPL,slot-name</key>
                <string>PCIEX4</string>
                <key>built-in</key>
                <data>AQ==</data>
                <key>device-id</key>
                <data>9hAAAA==</data>
                <key>device_type</key>
                <string>Ethernet Controller</string>
                <key>subsystem-id</key>
                <data>AAAAAA==</data>
                <key>subsystem-vendor-id</key>
                <data>AAAAAA==</data>
                <key>vendor-id</key>
                <data>hoAAAA==</data>
            </dict>
        </dict>
        <key>Delete</key>
        <dict/>
    </dict>

Explanation of the Device Properties

Code:
                <key>built-in</key>
                <data>AQ==</data>

Sets the "built-in" flag to 0x01 so that MacOS thinks it's a built-in device.

Code:
                <key>device-id</key>
                <data>9hAAAA==</data>

This changes the Intel 82574L device-id (Primary PID) to 0x10F60000 which is required for the primary PID match in Apples native 82574L kext driver, if you open the info.plist for the Intel82574L.kext you can see where we get this value from :-

View attachment 542465

Code:
                <key>device_type</key>
                <string>Ethernet Controller</string>

This is pretty self explanatory.

Code:
                <key>subsystem-id</key>
                <data>AAAAAA==</data>
                <key>subsystem-vendor-id</key>
                <data>AAAAAA==</data>
                <key>vendor-id</key>
                <data>hoAAAA==</data>

Sets the sub-system PID & VID to 0x00000000 and vendor-id (Primary VID) to 0x80860000 (Intel).

Step-3 - Patch the Intel82574L kext to ignore the Secondary PID & VID Match

Despite injecting the correct PID and VID values for both the primary and secondary PCI matches the native Apple kext still refused to bind it's self to the newly installed NIC. In order to fix this add the following to the Kernel->Patch section of your config.plist

Code:
            <dict>
                <key>Arch</key>
                <string>Any</string>
                <key>Base</key>
                <string></string>
                <key>Comment</key>
                <string>Intel 82574L Ethernet</string>
                <key>Count</key>
                <integer>0</integer>
                <key>Enabled</key>
                <true/>
                <key>Find</key>
                <data>SU9QQ0lTZWNvbmRhcnlNYXRjaA==</data>
                <key>Identifier</key>
                <string>com.apple.driver.Intel82574LEthernet</string>
                <key>Limit</key>
                <integer>0</integer>
                <key>Mask</key>
                <data></data>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string></string>
                <key>Replace</key>
                <data>RFVNTVlTZWNvbmRhcnlNYXRjaA==</data>
                <key>ReplaceMask</key>
                <data></data>
                <key>Skip</key>
                <integer>0</integer>
            </dict>
        </array>

This patch changes the <key> name IOPCISecondaryMatch in info.plist of the Intel82574L.kext to DUMMYSecondaryMatch thus effectually disabling secondary PID and VID matching.

Step-4 - Force MacOS to load the Intel82574L kext.

Create the following entry in the Kernel/Force section of your config.plist

Code:
        <key>Force</key>
        <array>
            <dict>
                <key>Arch</key>
                <string>x86_64</string>
                <key>BundlePath</key>
                <string>System\Library\Extensions\IONetworkingFamily.kext\Contents\PlugIns\Intel82574L.kext</string>
                <key>Comment</key>
                <string>For Intel 82574L NIC</string>
                <key>Enabled</key>
                <true/>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/Intel82574L</string>
                <key>Identifier</key>
                <string>com.apple.driver.Intel82574LEthernet</string>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string></string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
            </dict>
        </array>

This entry forces MacOS to load the Intel82574L kext regardless of the Mac model / SMBIOS you are using.

Step-5 - Final checks and Testing

After you have made the above changes and saved the updated config.plist, i recommend using OCValidate to check that there are no syntax or formatting errors, if the file passes validation then you can reboot and load MacOS again.

Run Hackintool again and check the entry for the Intel 82574L NIC, if everything has worked you should see that the devices Primary PID is now 0x10F6 and if you click on the magnifying glass icon for that entry you should see that the device is now attached to the Intel82574L.kext.

At this point you should find that the 82574L NIC is working.

View attachment 542466

I've been running my system with the Intel 82574L NIC for about two weeks now and it's been 100% stable with no issues with sleep and wake, since we are using a native Apple kext driver it's highly likely that "Wake on LAN" should also work although this is something that I haven't tested myself.

Cheers
Jay
I bought the very same NIC and followed your tutorial : Worked like a charm ! thanks a lot Jay !
Would you please explain how 9hAAAA translates to 0x10F60000 to match the PID ?
Understanding this would allow me to replicate this to other NICS (i210 for that matter).
 
I bought the very same NIC and followed your tutorial : Worked like a charm ! thanks a lot Jay !
Would you please explain how 9hAAAA translates to 0x10F60000 to match the PID ?
Understanding this would allow me to replicate this to other NICS (i210 for that matter).

@leborgne,

Glad you found the guide helpful and it worked for you.

99hAAAA== is the device-id in base64 (with the bytes reversed), you can use Hackintools Calculator function to do the conversion :-

Screenshot 2022-05-04 at 12.31.24.png
Cheers
Jay
 
@leborgne,

Glad you found the guide helpful and it worked for you.

99hAAAA== is the device-id in base64 (with the bytes reversed), you can use Hackintools Calculator function to do the conversion :-

View attachment 547127
Cheers
Jay
Ok great !
Will use that + your guide to try and make an i210 NIC work on my other Ryzentosh.
Thanks again jay.
 
This changes the Intel 82574L device-id (Primary PID) to 0x10F60000 which is required for the primary PID match in Apples native 82574L kext driver, if you open the info.plist for the Intel82574L.kext you can see where we get this value from :-

Primary PCI Match.png
Jay
Hi Jay,
Other dots I'm unable to connect : where do you get the 0x10F60000 value from the "IOPCIPrimaryMatch" key on your screenshot ?
 
Other dots I'm unable to connect : where do you get the 0x10F60000 value from the "IOPCIPrimaryMatch" key on your screenshot ?

@leborgne,

We get that from the Apple kext we want to patch.

Using the 82574L NIC as an example first we need to open the parent kext so navigate to :-

/System/Library/Extensions/IONetworkingFamily.kext

Secondary click on the kext and select "Show Contents"

Then drill down to the plugins folder and find the device specific kext you want to use :-
Using the 82574L again as an example this would be :-

/Contents/PlugIns/Intel82574L.kext

Secondary click on the kext and select "Show Contents"
Then open the info.plist of the kext in a plist editor.
From here we can find all the info we need to patch the kext using OpenCore.

Cheers
Jay
 
@leborgne,

We get that from the Apple kext we want to patch.

Using the 82574L NIC as an example first we need to open the parent kext so navigate to :-

/System/Library/Extensions/IONetworkingFamily.kext

Secondary click on the kext and select "Show Contents"

Then drill down to the plugins folder and find the device specific kext you want to use :-
Using the 82574L again as an example this would be :-

/Contents/PlugIns/Intel82574L.kext

Secondary click on the kext and select "Show Contents"
Then open the info.plist of the kext in a plist editor.
From here we can find all the info we need to patch the kext using OpenCore.

Cheers
Jay
Hi Jay,
Yeah I got this part but the one I don't is why, in your case, did you use 0x10F60000 instead of the values given in the info.plist file (0x104b8086 or 0x10f68086) ?
 
why, in your case, did you use 0x10F60000 instead of the values given in the info.plist file (0x104b8086 or 0x10f68086) ?

@leborgne,

In most cases only the PID (the first two bytes, IE 0x10F6) are significant when dealing with device-id matching, the Vendor ID (the last two bytes, IE 0x8086) tend not to be used. The method should work fine if you use 8086 as the VID, the only reason i used 0000 is out of habbit from the days when i did a lot of IGPU patching.

Cheers
Jay
 
Back
Top