Ethernet "Not connected"

[Riko_KP]

Hello everyone!

I have been working with a Hackintosh build for a while now, and it has served me well. I have not had any real problems that I couldn't fix with a bit of banging my head on the wall and asking for help on the forums.
After updating from Monterey to Ventura, I noticed a bit of an annoying quirk. My Ethernet has never worked and it has not been a problem until Ventura, upon booting my Wi-fi takes really long to initialize and connect to my network, sometimes upwards of one minute and once it didn't connect at all before rebooting. Now enabling ethernet would definitely fix this issue, but I don't know what I'm missing because it just won't connect. I have the required files for it, and it is recognized by macOS but just will not connect to the internet. I have SSDT-I225V.aml in my ACPI folder, and the required AppleIntelI210Ethernet.kext, I also have the boot-arg e1000=0, but nothing. I have no clue where to start looking and what to try at this point to fix it. Any help is appreciated!




My build:
AMD Ryzen 5 5600 3.5GHz
AMD Radeon RX 6600 XT
16 GB 3600 MHz DDR4
ASRock B550 Phantom Gaming ITX/ax
Ventura 13.0.1

 

[Edhawk]

Which WiFi card are you using?

If you are using an Intel WiFi card: Have you checked to see if you are using the correct kext for Ventura, as the kext that worked in Monterey may not be compatible in Ventura. Specifically Airportitlwm.kext, as there are different versions of this kext for the last 5 or 6 major releases of macOS (High Sierra onwards).

No kext specifically for Ventura,

So if you were using Airportitlwm.ket in Monterey you may need to switch to Itlwm.kext & Heliport App in Monterey.

If it is a WiFi/BT combo card, are you seeing issues with the Bluetooth, as that also requires some edits/changes.

Regarding your Ethernet controller (1225-V) I have read conflicting posts stating that disabling or enabling VT-d in the bios, or enabling the Kernel > Quirks > DisableIoMapper entry in the OC config.plist can help with the Ethernet port. So switching DisableIoMapper from its present setting to the opposite i.e. False to True or True to False may help.

 

[CaseySJ]

The file SSDT-I225V.aml needs to be adapted to each motherboard. More specifically, the 2.5GbE port on your board may have a different PCI path than the one currently in the file. If you post your IOReg file, we can determine what needs to be done.

IOReg file is generated by downloading and running IORegistryExplorer and selecting File --> Save As...

 

[Riko_KP]

The file SSDT-I225V.aml needs to be adapted to each motherboard. More specifically, the 2.5GbE port on your board may have a different PCI path than the one currently in the file. If you post your IOReg file, we can determine what needs to be done.

IOReg file is generated by downloading and running IORegistryExplorer and selecting File --> Save As...

Hey, thanks for the reply! You are correct, I have not edited SSDT-I225V.aml at all, and am not sure as to how to even go about it. I will attach my IOReg here, so if you can say something about it and point me in the right direction, that would be great.

Right, can't attach .ioreg files, here's a Dropbox link where you can get it:

IOReg.ioreg

Shared with Dropbox

www.dropbox.com

 

[Edhawk]

Can't open the IOReg file. Get this message when I try.



When you saved the IOReg file why did you add the .ioreg extension?

You don't need to do that, just use the 'Save as...' option and leave the name as it is. Then compress the file and attach it to a post using the 'Attach Files' button below the post.

 

[Riko_KP]

Can't open the IOReg file. Get this message when I try.

View attachment 9271

When you saved the IOReg file why did you add the .ioreg extension?

You don't need to do that, just use the 'Save as...' option and leave the name as it is. Then compress the file and attach it to a post using the 'Attach Files' button below the post.

That is exactly what I did. It always saves it as a .ioreg file no matter what I do.

 

[Riko_KP]

Here you go, compressing the file let me upload it.

 

[Edhawk]

Same again, IOReg is corrupted and can't be opened.



Probably down to the version of IORegistryExplorer you are using. Download and use the dmg on this Github page.

Release v2.1 · vulgo/IORegistryExplorer

IORegistryExplorer v2.1 Copyright 2000-2008 Apple Inc. All Rights Reserved.

github.com

I am using IORegistryExplorer version 2.1 linked above.

Some newer versions don't play well when sharing an IOReg.

 

[Riko_KP]

Same again, IOReg is corrupted and can't be opened.

View attachment 9284

Probably down to the version of IORegistryExplorer you are using. Download and use the dmg on this Github page.

Release v2.1 · vulgo/IORegistryExplorer

IORegistryExplorer v2.1 Copyright 2000-2008 Apple Inc. All Rights Reserved.

github.com

I am using IORegistryExplorer version 2.1 linked above.

Some newer versions don't play well when sharing an IOReg.

Well isn't this quite the conundrum. I cannot install that version.



Edit: Nevermind, got it. Try this.

 

[Edhawk]

That one works and is readable!

These are the details for the i225-V Ethernet controller in your IOReg.

Ethernet & WiFi devices on /_SB.PCI0.GPP1 pci-bridge@2

But with different sub-pci-bridges.

• Ethernet - pci-bridge@8,
• WiFi - pci-bridge@9

You may need to use Corpnewt's SSDTTime python script to confirm the PCI Bridge address for the Ethernet controller. So you can provide the full address in the SSDT-i225V.aml

(_SB.PCI0.GPP1) details

Ethernet@0 details

Device-ID is set for i225-V not i225-LM, so I assume you do not have a fake device-id present in your config.plist.
Device-ID for your i225-V is most probably present in the SSDT, but not being read correctly, if the ACPI address is not being provided and read correctly.
You seem to have the model details included in either your config.plist or the SSDT-i225V.aml table, as the IOReg is showing model as <"Intel(R) Ethernet Controller I225-V">.
Usually device-id > Data > F2150000 is required in the DeviceProperties section of the config.plist, to fake the i225-V as an i225-LM.
At least that was the case when I was messing with a Comet Lake system's i225-V Ethernet controller.

 

[Riko_KP]

That one works and is readable!

These are the details for the i225-V Ethernet controller in your IOReg.

View attachment 9286 Ethernet & WiFi devices on /_SB.PCI0.GPP1 pci-bridge@2

But with different sub-pci-bridges.

• Ethernet - pci-bridge@8,
• WiFi - pci-bridge@9

You may need to use Corpnewt's SSDTTime python script to confirm the PCI Bridge address for the Ethernet controller. So you can provide the full address in the SSDT-i225V.aml

View attachment 9287 (_SB.PCI0.GPP1) details

View attachment 9288 Ethernet@0 details

Device-ID is set for i225-V not i225-LM, so I assume you do not have a fake device-id present in your config.plist.
Device-ID for your i225-V is most probably present in the SSDT, but not being read correctly, if the ACPI address is not being provided and read correctly.
You seem to have the model details included in either your config.plist or the SSDT-i225V.aml table, as the IOReg is showing model as <"Intel(R) Ethernet Controller I225-V">.
Usually device-id > Data > F2150000 is required in the DeviceProperties section of the config.plist, to fake the i225-V as an i225-LM.
At least that was the case when I was messing with a Comet Lake system's i225-V Ethernet controller.

Thank you for the reply!

I have a couple of questions, how do I determine the correct address for the Ethernet controller and how do I add it to SSDT-i225.aml?
Also, where exactly do I add the device-id in my config.plist? This is not something I have had to do before and do not know where to add the F2150000.

There is another user on the forum with the exact same build as me, but has not had to take these extra steps to get the Ethernet working, which is odd.

 

[Edhawk]

Have you examined the other user's Ethernet settings?
What if anything is different to your current Ethernet settings?
Which other user?

You add the device-id for any device to the DeviceProperties section of your OC config.plist. Under the specific ACPI address for the Ethernet controller.
The ACPI Address for the Ethernet controller can be obtained from Hackintool > PCIe tab. Stretching the Hackintool window to display all the details and looking under the 'Device Path' column. As shown in the example below.

Hackintool > PCIe tab extended window to show all details.

You can use the 'Export' icon (right hand icon below main window) to dump this information on your desktop. The info dump creates 4 x files, with the pcidevices.plist being the one to show the necessary Device Path for each and every device in your system. Some of these entries can be added to the DeviceProperties section of your config.plist to help the system work better. add a fake device-id and set them as 'built-in' if they are not automatically set that way.

Files dumped on Desktop from Hackintool > PCIe > Export function.

Compressing and posting a copy of your pcidevices.plist would be helpful, as it will show us the Device Paths for all the devices on your system.

While you are at it compress and post a copy of your OC EFI folder, so we can see what you are using and just as importantly what you are not using to configure your system.

 

[Riko_KP]

Have you examined the other user's Ethernet settings?
What if anything is different to your current Ethernet settings?
Which other user?

You add the device-id for any device to the DeviceProperties section of your OC config.plist. Under the specific ACPI address for the Ethernet controller.
The ACPI Address for the Ethernet controller can be obtained from Hackintool > PCIe tab. Stretching the Hackintool window to display all the details and looking under the 'Device Path' column. As shown in the example below.

View attachment 9311 Hackintool > PCIe tab extended window to show all details.

You can use the 'Export' icon (right hand icon below main window) to dump this information on your desktop. The info dump creates 4 x files, with the pcidevices.plist being the one to show the necessary Device Path for each and every device in your system. Some of these entries can be added to the DeviceProperties section of your config.plist to help the system work better. add a fake device-id and set them as 'built-in' if they are not automatically set that way.

View attachment 9312 Files dumped on Desktop from Hackintool > PCIe > Export function.

Compressing and posting a copy of your pcidevices.plist would be helpful, as it will show us the Device Paths for all the devices on your system.

While you are at it compress and post a copy of your OC EFI folder, so we can see what you are using and just as importantly what you are not using to configure your system.

The other user is called varkon, I believe I have mostly the same settings in general, as well as regarding the Ethernet, as they do. I do have a few other fixes in the form of kexts that I have tried for the Ethernet but other than that, I think everything is exactly the same. I have seen his config.plist as I had to check a few things from there to get my build fully working.
From the looks of it, the Device Path seems to be correct in all my files if I am reading it right.

Here, I have the pcidevices.plist and EFI file in the attachments.

Edit: I tried adding the device-id > Data > F2150000 into my config.plist, but that had no effect.

 

[Edhawk]

Questions:

1. Did you remove the additional kexts and patches you previously installed, when they didn’t fix your Ethernet issues?
2. Did you use the ResetNvramEntry.EFI from the OC boot screen, after adding the i225-LM device-Id to your config?

 

[Riko_KP]

Questions:

1. Did you remove the additional kexts and patches you previously installed, when they didn’t fix your Ethernet issues?
2. Did you use the ResetNvramEntry.EFI from the OC boot screen, after adding the i225-LM device-Id to your config?

1. Yes, I have since removed IntelMausi.kext as that is what I tried to use.
2. Yes, I did reset to no avail.

Ethernet is still somehow seen but "Not connected".

 

[Edhawk]

Reason the Ethernet doesn't work is because the SSDT-i255V.aml table is using a different device path, compared to the path seen in the IOReg.

The path used in the SSDT is (_SB.PCI0.RP02.D066)
The path seen in the IOReg is (_SB.PCI0.GPP1) pci-bridge@2 and pci-bridge@8

SSDT-i225V.aml table contents, wrong device path for Ethernet controller.

Changing the path might fix this issue, but I still think the 2 x pci-bridge sections may need to be discovered.

Post a copy of your system DSDT.aml so I can see what is going on in your system.

You are using the correct device paths for the WiFi and Ethernet controllers in your OC config.plist.

Another question is whether you need all the 'Fixes' in your system enabled at the same time.

Other issues:

A possible reason for some of your issues, specifically the Sleep/Wake issues, is the UTBMap.kext you are currently using. It doesn't match your motherboard's USB ports, not even close.

Your motherboard has the following USB ports available.
Rear panel:

- 1 x USB 3.2 Gen2 Type-A Port (10 Gb/s)​

- 1 x USB 3.2 Gen2 Type-C Port (10 Gb/s)​

- 4 x USB 3.2 Gen1 Ports​

Maximum of 12 x USB ports if all are active/enabled.

​

Internal headers:

- 1 x USB 2.0 Header (Supports 2 USB 2.0 ports)​

- 1 x USB 3.2 Gen1 Header (Supports 2 USB 3.2 Gen1 ports)​

- 1 x Front Panel Type C USB 3.2 Gen2 Header​

- 1 x USB 2.0 served from the M.2 WiFi/BT connector​

Maximum of 9 x USB ports if all are active/enabled.

This means your UTBMap should have the following 21 x USB ports enabled/activated if all are in use:

3 x Internal ports with connector type (255) (USB 2.0 header and BT connector from M.2)​

0 x USB2 physical ports with connector type (0) - your motherboard doesn't have any physical USB2 ports​

7 x USB3 physical ports with connector type (3) (5 x USB3 physical ports on rear and 2 x USB 3 ports from Header)​

7 x USB2 virtual ports served from the 7 x USB3 physical ports, with connector type (3)​

2 x Type-C physical ports with connector type (9) or (10)​

2 x Type-C virtual USB2 ports with connector type (9) or (10)​

As your motherboard has 2 x USB controllers, your system could theoretically support the activation of up to 30 x USB ports, 15 x USB ports per USB controller.

* 500 Series Chipset USB 3.1 XHCI Controller​

* Matisse USB 3.0 Host Controller​

​

Your UTBMap.kext/contents/info.plist has the following USB ports being activated:

1 x Internal port with connector type (255) - probably your Intel bluetooth module from the M.2 WiFi/BT connector​

1 x USB2 physical port with connector type (0) - there are no physical USB2 ports on your motherboard, so this is wrong.​

3 x USB3 physical ports with connector type (3)​

3 x USB2 virtual ports served from USB3 physical ports with connector type (3)​

0 x Type-C physical or virtual ports. This is fine if you don't use them.​

​

So basically your USB configuration is a waste of space. Bit like the SSDT-i225V.aml table. As neither will be working correctly in your system.

Ethernet, again:
You still have the IntelMausi.kext in your /EFI/OC/Kexts folder with a companion entry in your config.plist activating the kext. This should be removed, as it does nothing for your system.

The AppleInteli210Ethernet.kext in your OC setup contains both the i225-V and i225-LM device ID's. So there should be no need to fake the device ID. Top two entries in the IONameMatch shown in the screenshot below.



SSDT's:
The SSDT-SLEEP.aml table in your /EFI/OC/ACPI folder is not doing anything for your system. Your system doesn't have any devices on the (_SB.PCI0.GPP2) or (_SB.PCI0.GPP2.PTXH) path. It should be removed.

SSDT-SLEEP.aml table contents, wrong device path

If you fix your USB configuration, you may not need an SSDT to allow your system to sleep/wake correctly.

 

[Riko_KP]

Reason the Ethernet doesn't work is because the SSDT-i255V.aml table is using a different device path, compared to the path seen in the IOReg.

The path used in the SSDT is (_SB.PCI0.RP02.D066)
The path seen in the IOReg is (_SB.PCI0.GPP1) pci-bridge@2 and pci-bridge@8

View attachment 9335 SSDT-i225V.aml table contents, wrong device path for Ethernet controller.

Changing the path might fix this issue, but I still think the 2 x pci-bridge sections may need to be discovered.

Post a copy of your system DSDT.aml so I can see what is going on in your system.

You are using the correct device paths for the WiFi and Ethernet controllers in your OC config.plist.

Another question is whether you need all the 'Fixes' in your system enabled at the same time.

Other issues:

A possible reason for some of your issues, specifically the Sleep/Wake issues, is the UTBMap.kext you are currently using. It doesn't match your motherboard's USB ports, not even close.

Your motherboard has the following USB ports available.
Rear panel:

- 1 x USB 3.2 Gen2 Type-A Port (10 Gb/s)​

- 1 x USB 3.2 Gen2 Type-C Port (10 Gb/s)​

- 4 x USB 3.2 Gen1 Ports​

Maximum of 12 x USB ports if all are active/enabled.

​

Internal headers:

- 1 x USB 2.0 Header (Supports 2 USB 2.0 ports)​

- 1 x USB 3.2 Gen1 Header (Supports 2 USB 3.2 Gen1 ports)​

- 1 x Front Panel Type C USB 3.2 Gen2 Header​

- 1 x USB 2.0 served from the M.2 WiFi/BT connector​

Maximum of 9 x USB ports if all are active/enabled.

This means your UTBMap should have the following 21 x USB ports enabled/activated if all are in use:

3 x Internal ports with connector type (255) (USB 2.0 header and BT connector from M.2)​

0 x USB2 physical ports with connector type (0) - your motherboard doesn't have any physical USB2 ports​

7 x USB3 physical ports with connector type (3) (5 x USB3 physical ports on rear and 2 x USB 3 ports from Header)​

7 x USB2 virtual ports served from the 7 x USB3 physical ports, with connector type (3)​

2 x Type-C physical ports with connector type (9) or (10)​

2 x Type-C virtual USB2 ports with connector type (9) or (10)​

As your motherboard has 2 x USB controllers, your system could theoretically support the activation of up to 30 x USB ports, 15 x USB ports per USB controller.

* 500 Series Chipset USB 3.1 XHCI Controller​

* Matisse USB 3.0 Host Controller​

​

Your UTBMap.kext/contents/info.plist has the following USB ports being activated:

1 x Internal port with connector type (255) - probably your Intel bluetooth module from the M.2 WiFi/BT connector​

1 x USB2 physical port with connector type (0) - there are no physical USB2 ports on your motherboard, so this is wrong.​

3 x USB3 physical ports with connector type (3)​

3 x USB2 virtual ports served from USB3 physical ports with connector type (3)​

0 x Type-C physical or virtual ports. This is fine if you don't use them.​

​

View attachment 9332
So basically your USB configuration is a waste of space. Bit like the SSDT-i225V.aml table. As neither will be working correctly in your system.

Ethernet, again:
You still have the IntelMausi.kext in your /EFI/OC/Kexts folder with a companion entry in your config.plist activating the kext. This should be removed, as it does nothing for your system.

The AppleInteli210Ethernet.kext in your OC setup contains both the i225-V and i225-LM device ID's. So there should be no need to fake the device ID. Top two entries in the IONameMatch shown in the screenshot below.

View attachment 9333

SSDT's:
The SSDT-SLEEP.aml table in your /EFI/OC/ACPI folder is not doing anything for your system. Your system doesn't have any devices on the (_SB.PCI0.GPP2) or (_SB.PCI0.GPP2.PTXH) path. It should be removed.

View attachment 9334 SSDT-SLEEP.aml table contents, wrong device path

If you fix your USB configuration, you may not need an SSDT to allow your system to sleep/wake correctly.

Thank you for troubleshooting, I appreciate it a lot.

First of all, I need to know how to fix the address in SSDT-i225.aml, how do I open the file and where do I add the correct address? It won't open correctly using TextEdit (which is the default app). I think this would be the best first step to take.
I will attach my DSDT.aml later if I can, SSDTTime would not dump my DSDT before when I tried no matter what I did, I will try that again.

Second, I don't understand how my UTBMap.kext is faulty since I made it myself using USBToolBox. I thought I had it right, but clearly not. I do not know how to properly map the ports.
Sleep/Wake aren't actually a problem for me, however, as I never use the Sleep function, but rather turn off the system completely when I am not using it so I hadn't even noticed this.

Regarding IntelMausi.kext, I have since deleted the kext and the entry from my config.plist, so that is not an issue. It had no effect on anything anyway.

 

[Edhawk]

After a bit of searching I found where your SSDT-i225V.aml table came from, a guide for an Intel Z490 Vision-G system! No wonder it doesn't work.

The way to edit the SSDT-i225V.aml table is to first Decompile/Disassemble the table, using the correct Terminal commands, so it is saved as SSDT-i225V.dsl table. Only when it has been decompiled/disassembled can it be edited correctly using maciASL. You cannot edit and save an .aml table and expect it to work, it won't.

Use Hackintool to dump your ACPI tables, navigate to the Utilities tab, select the Dump ACPI icon (4th from right)

Hackintool > Utilities tab > Dump ACPI icon

This will ask you to create or point to a folder where the ACPI tables are to be saved. I usually create a new folder named 'ACPI Dump' on my desktop, so it is easy to find. It can be moved to a different location once you have compressed the folder for attaching to a post here.

 

[Riko_KP]

After a bit of searching I found where your SSDT-i225V.aml table came from, a guide for an Intel Z490 Vision-G system! No wonder it doesn't work.

The way to edit the SSDT-i225V.aml table is to first Decompile/Disassemble the table, using the correct Terminal commands, so it is saved as SSDT-i225V.dsl table. Only when it has been decompiled/disassembled can it be edited correctly using maciASL. You cannot edit and save an .aml table and expect it to work, it won't.

Use Hackintool to dump your ACPI tables, navigate to the Utilities tab, select the Dump ACPI icon (4th from right)

View attachment 9336 Hackintool > Utilities tab > Dump ACPI icon

This will ask you to create or point to a folder where the ACPI tables are to be saved. I usually create a new folder named 'ACPI Dump' on my desktop, so it is easy to find. It can be moved to a different location once you have compressed the folder for attaching to a post here.

Yes, I could not find one that would be one-to-one with my system, as varkon, for some reason, doesn't have the SSDT-i225V.aml, yet he linked this guide https://github.com/5T33Z0/Gigabyte-Z490-Vision-G-Hackintosh-OpenCore/blob/main/I225-V_FIX.md on his own build. He doesn't say exactly what he did to get his Ethernet up and running, but refers to this.

I will try to edit the SSDT-i225V.aml and see what happens. Will report once it is done.

Edit: Added ACPI Dump.

Edit2: So I tried to decompile the SSDT-I225.aml using iasl-stable through terminal, but all I got was zsh: permission denied: /Users/riko/Desktop/iasl-stable

 

[Edhawk]

I will have a look at the ACPI tables tomorrow and see if I can extract the full device path for the Ethernet controller.