Jump to content

macOS Sonoma Wireless Issues Discussion.

SavageAUS

By SavageAUS,
in LAN and Wireless

 Share
807 posts in this topic

Recommended Posts

FirstTimeCustomac
FirstTimeCustomac
Posted
Posted

For the record, with AMFIPass.kext, I did not need AMFI disabled for applying root patches for Nvidia Kepler, Modern Wireless, Legacy USB1,1 in macOS Ventura or Sonoma. OCLP applies root patches fine, system boots fine and AMFI does not need to stay disabled for them to function.

  • Like 3
  • Thanks 1
deeveedee
deeveedee
Posted
Posted (edited)

 

2 hours ago, FirstTimeCustomac said:

Agreed. If I may add, for me, nightly build of OCLP 0.6.8 for Sonoma wasn't able to root patch with AmfiPass.kext 1.3.1 with warning "AMFI is enabled" and AMFI had to be disabled. but no problem on iMac19,1 with OCLP 0.6.9

 

I think the key is "nightly build of OCLP 0.6.8."  I didn't experiment with OCLP 0.6.8 / AMFIPass until the release version of 0.6.8.  Prior to the 0.6.8 Release, I was using the AMFIPass.kext Beta branch of OCLP.  If you are able to test, I'd be curious to know if OCLP 0.6.8 release has fixed this for you.

 

EDIT: When I was first using DosDude's patchers for Mojave and Catalina (before the availability of OCLP), I needed AMFI to be disabled (using amfi_get_out_of_my_way=1 boot-arg, same as amfi=0x80 boot-arg) in order to apply DosDude patches for Nvidia Tesla.  Before the availability of AMFIPass.kext, I needed AMFI disabled in order to be able to use OCLP to apply post-install Nvidia Tesla patches to Big Sur, Monterey, Ventura and Sonoma.   With the release of AMFIPass.kext, I no longer need to disable AMFI for any macOS version starting with Big Sur.

 

It is incorrect to claim that AMFIPass.kext has nothing to do with OCLP post-install patches.  It is also incorrect to claim that AMFIPass.kext is not a requirement on Big Sur.  As stated here (see EDIT2), the need for AMFIPass.kext may depend on SMBIOS and graphics.  There has been inaccurate information shared in this thread about OCLP and AMFIPass.kext.  I would suggest that each person test AMFIPass.kext on their own hack to confirm the best solution for you.

Edited by deeveedee
miliuco
miliuco
Posted
Posted

@FirstTimeCustomac  @deeveedee

 

I'll give a new try, to check if I can apply root patch on my system with AMFIPass.kext, last time I was able only with AMFI disabled, once patch applied the system runs fine with AMFIPass.kext.

  • Like 3
FirstTimeCustomac
FirstTimeCustomac
Posted
Posted (edited)
1 hour ago, deeveedee said:

 

 

I think the key is "nightly build of OCLP 0.6.8."  I didn't experiment with OCLP 0.6.8 / AMFIPass until the release version of 0.6.8.  Prior to the 0.6.8 Release, I was using the AMFIPass.kext Beta branch of OCLP.  If you are able to test, I'd be curious to know if OCLP 0.6.8 release has fixed this for you.

 

Here is my testing result.

 

OCLP 0.6.7 Release + AMFIPass.kext 1.2.1 in Ventura:  "AMFI is enabled" warning

OCLP 0.6.7 AMFIPass Beta Build + AMFIPass.kext 1.2.1 in Ventura: OK

OCLP 0.6.8 Release + AMFIPass.kext 1.2.1 in Ventura: OK  

 

OCLP 0.6.8 Sonoma Build + AMFIPass.kext 1.3.1 in Sonoma: "AMFI is enabled" warning

OCLP 0.6.9 Sonoma Build + AMFIPass.kext 1.3.1 in Sonoma: OK 

 

Edit: For my system, starting with OCLP 0.6.7 AMFIPass beta build, AMFI did not need to be disabled in order to apply root patches. OCLP 0.6.8 is the first release with AMFIPass.kext and I think OCLP 0.6.8 Sonoma nightly build was out before the OCLP 0.6.8 released build?

 

Edit2: Sorry, I included OCLP 0.6.7 in my testing to make a point that since its AMFIPass.kext beta, my system did not need amfi=0x80 for root patching not to make any confusion.

Edited by FirstTimeCustomac
  • Thanks 1
deeveedee
deeveedee
Posted
Posted (edited)
49 minutes ago, FirstTimeCustomac said:

Edit: For my system, starting with OCLP 0.6.7 AMFIPass Beta Build, AMFI did not need to be disabled in order to apply root patches. OCLP 0.6.8 is the first released build with AMFIPass.kext and I think OCLP 0.6.8 Sonoma nightly build was out before the OCLP 0.6.8 released build?

 

I didn't remember that there was an "OCLP 0.6.8 Sonoma nightly build" and don't currently use it.  I only use OCLP 0.6.8 Release (for patching Big Sur, Monterey and Ventura) and OCLP 0.6.9 Sonoma nightly build (for patching Sonoma).  Unfortunately, the OCLP Devs are using overlapping version numbering that can be confusing (not a criticism since they're doing an awesome job - just an observation).   I am currently avoiding the confusion by using only the OCLP 0.6.8 Release (again for Big Sur, Monterey and Ventura) and only using OCLP 0.6.9 Sonoma nightly builds for Sonoma testing.

 

EDIT: On my HackBookPro6,2, I currently boot Big Sur, Monterey, Ventura and Sonoma with a single OC 0.9.4 EFI (AMFI and LV fully enabled, AMFIPass.kext 1.3.1).  All versions of macOS are on separate APFS volumes in a single APFS container on a single SSD.  I patch Big Sur, Monterey and Ventura with OCLP 0.6.8 Release and Sonoma with OCLP 0.6.9 Sonoma nightly build.  Since OCLP post install patches do not touch the EFI, I have no problems with this "hybrid" post-install patching solution.

Edited by deeveedee
  • Like 1
cankiulascmnfye
cankiulascmnfye
Posted
Posted
  1. Whether or not AMFI needs to be ENBALED DEPENDS ON THE TYPE OF PATCHES YOU WANT TO APPLY.
  2. The primary purpose of AMFIPASS IS NOT TO APPLY ROOT PATCHES TO SYSTEMS BUT TO BE ABLE TO GRANT APPS ACCESS TO CAMERAS AND MICS:
    Quote

    Due to the usage of amfi_get_out_of_my_way=1, macOS will fail to prompt users for special permissions upon application start as well as omit the entires in System Preferences. To work around this, we recommend users install tccplus to manage permissions.

     

    SOURCE: https://dortania.github.io/OpenCore-Legacy-Patcher/ACCEL.html#unable-to-grant-special-permissions-to-apps-ie-camera-access-to-zoom

  3. Especially on clean installs! When upgrading to a newer version, access settings to cameras and mics from previous versions, where AMFI didn't need to be disabled are inherited from the previous install (if they were granted!

 

@SavageAUS You simply download Amfipass from the OCLP Repo: https://github.com/dortania/OpenCore-Legacy-Patcher/tree/sonoma-development/payloads/Kexts/Acidanthera

 

 

deeveedee
deeveedee
Posted
Posted (edited)
2 hours ago, FirstTimeCustomac said:

Edit2: Sorry, I included OCLP 0.6.7 in my testing to make a point that since its AMFIPass.kext beta, my system did not need amfi=0x80 for root patching not to make any confusion.

Not your fault at all.  Before the OCLP Devs changed AMFIPass Beta branch of OCLP to "amfipass-beta4," it was numbered 0.6.7 (the same as the concurrent OCLP 0.6.7 release version that had nothing to do with AMFIPass).  Very confusing.

Edited by deeveedee
eSaF
eSaF
Posted
Posted
6 minutes ago, miliuco said:

@D-an-W

Not on my side, Eth and wifi both are running fine after OCLP root patching.

Same here.

Stupid and simple as it sounds, try clicking on 'Renew Lease' and see what happens.

  • Like 2
  • Thanks 1
deeveedee
deeveedee
Posted
Posted

@D-an-W I haven't noticed this.  I just upgraded from Sonoma 14.0 Beta 4 -> Beta 5 with the Wi-Fi spoofing patch in place as described here and all is good.  If you post your EFI (remove personal platform info from config.plist), we can take a look.

  • Like 1
  • Thanks 1
AppleBreak
AppleBreak
Posted
Posted (edited)
21 minutes ago, D-an-W said:

Has anyone noticed their Ethernet no longer connects after making the required changes and rebooting to apply the OCLP patch (Also doesn't work with the patch applied but WiFi does)?

 

Please try AppleIGC.kext with e1000=0 boot flag instead. It may be caused by injecting the old IOSkywalkFamily.kext as mentioned in below post.

 

Edited by AppleBreak
  • Like 2
  • Thanks 1
miliuco
miliuco
Posted
Posted (edited)
15 minutes ago, eSaF said:

Stupid and simple as it sounds, try clicking on 'Renew Lease' and see what happens.

 

@D-an-W has a 2.5Gb Intel Ethernet, I guess, I'm afraid that the fix is not so simple.

 

 

9 minutes ago, D-an-W said:

Is it safe to disable the blocking of com.apple.iokit.IOSkywalkFamily with the patch applied to test if that is the cause?

 

if you disable IOSkywalkFamily blocking you'll get kernel panic. 

Edited by miliuco
  • Thanks 2
D-an-W
D-an-W
Posted
Posted (edited)
19 minutes ago, AppleBreak said:

 

Please try AppleIGC.kext with e1000=0 boot flag instead. It may be caused by injecting the old IOSkywalkFamily.kext as mentioned in below post.

 

 

Loading that kext did the trick, typing this I just realised I forgot to set the e1000=0 boot flag but it still works.

 

EDIT: It also works with the boot flag e1000=0 as advised.

Edited by D-an-W
  • Like 2
FirstTimeCustomac
FirstTimeCustomac
Posted
Posted
11 minutes ago, D-an-W said:

Is it safe to disable the blocking of com.apple.iokit.IOSkywalkFamily with the patch applied to test if that is the cause?

Disable both blocking and injecting IOSkywalkFamily? You'd get kernel panic if you only block com.apple.iokit.IOSkywalkFamily. You'd lose broadcom wifi as well.

  • Like 1
  • Thanks 1
cankiulascmnfye
cankiulascmnfye
Posted
Posted (edited)

Modern vs Legacy Wifi Patching – a look into OCLPs source code.

 

Path/File: OpenCore-Legacy-Patcher-sonoma-development/data/sys_patch_dict.py:

What: Modern Wireless Patching installs the following:

 

Spoiler 
 # May lord have mercy on our souls
 # Applicable for BCM943324, BCM94331, BCM94360, BCM943602
                "Modern Wireless": {
                    "Display Name": "Networking: Modern Wireless",
                    "OS Support": {
                        "Minimum OS Support": {
                            "OS Major": os_data.os_data.sonoma,
                            "OS Minor": 0
                        },
                        "Maximum OS Support": {
                            "OS Major": os_data.os_data.max_os,
                            "OS Minor": 99
                        },
                    },
                    "Install": {
                        "/usr/libexec": {
                            "airportd":       "13.5",
                            "wifianalyticsd": "13.5",
                            "wifip2pd":       "13.5",
                        },
                        "/System/Library/CoreServices": {
                            "WiFiAgent.app": "13.5",
                        },
                        "/System/Library/Frameworks": {
                            "CoreWLAN.framework": "13.5",
                        },
                        "/System/Library/PrivateFrameworks": {
                            "CoreAnalytics.framework":  "13.5",
                            "CoreWiFi.framework":       "13.5",
                            "IO80211.framework":        "13.5",
                            "WiFiAnalytics.framework":  "13.5",
                            "WiFiPolicy.framework":     "13.5",
                            "WiFiPeerToPeer.framework": "13.5",
                        },
                    },
                },
            },

 

 

Vs: Legacy Wireless Patching, which installs the following

 

Spoiler 
            "Networking": {
                "Legacy Wireless": {
                    "Display Name": "Networking: Legacy Wireless",
                    "OS Support": {
                        "Minimum OS Support": {
                            "OS Major": os_data.os_data.monterey,
                            "OS Minor": 0
                        },
                        "Maximum OS Support": {
                            "OS Major": os_data.os_data.max_os,
                            "OS Minor": 99
                        },
                    },
                    "Install": {
                        "/usr/libexec": {
                            "airportd": "11.7.1",
                        },
                        "/System/Library/CoreServices": {
                            "WiFiAgent.app": "11.7.1",
                        },
                    },
                    "Install Non-Root": {
                        "/Library/Application Support/SkyLightPlugins": {
                            **({ "CoreWLAN.dylib": "SkyLightPlugins" } if self.os_major == os_data.os_data.monterey else {}),
                            **({ "CoreWLAN.txt": "SkyLightPlugins" } if self.os_major == os_data.os_data.monterey else {}),
                        },
                    },
                },
                "Legacy Wireless Extended": {
                    "Display Name": "",
                    "OS Support": {
                        "Minimum OS Support": {
                            "OS Major": os_data.os_data.ventura,
                            "OS Minor": 0
                        },
                        "Maximum OS Support": {
                            "OS Major": os_data.os_data.max_os,
                            "OS Minor": 99
                        },
                    },
                    "Install": {
                        "/usr/libexec": {
                            "wps": "12.6.2",
                        },
                        "/System/Library/Frameworks": {
                            "CoreWLAN.framework": "12.6.2",
                        },
                        "/System/Library/PrivateFrameworks": {
                            "CoreWiFi.framework": "12.6.2",
                            "IO80211.framework":  "12.6.2",
                            **({ "CoreAnalytics.framework": "13.5"} if self.os_major >= os_data.os_data.sonoma else {}),
                            **({ "WiFiAnalytics.framework": "13.5"} if self.os_major >= os_data.os_data.sonoma else {}),
                        },
                    },
                },

 

 

Comparing both sections should make it clear, that Modern and Legacy patching are in fact installing different files, versions of files and Wifi Agent app. That's why enabling both patching methods in OCLP won't have the disired effect!

 

A Look into resources/build/networking/wireless.py reveals how a spoof for Legacy Wifi Patching for Broadcom and Atheros might work:

  

def _wifi_fake_id(self) -> None:
        """
        Fake Device ID Handler for BCM943224 and BCM94331 chipsets

        BCM94331 and BCM943224 are both partially supported within Big Sur's native AirPortBrcmNIC stack
        Simply adding the Device IDs and usage of AirPortBrcmFixup will restore full functionality
        """

        support.BuildSupport(self.model, self.constants, self.config).enable_kext("AirportBrcmFixup.kext", self.constants.airportbcrmfixup_version, self.constants.airportbcrmfixup_path)
        support.BuildSupport(self.model, self.constants, self.config).get_kext_by_bundle_path("AirportBrcmFixup.kext/Contents/PlugIns/AirPortBrcmNIC_Injector.kext")["Enabled"] = True
        if not self.constants.custom_model and self.computer.wifi and self.computer.wifi.pci_path:
            arpt_path = self.computer.wifi.pci_path
            logging.info(f"- Found ARPT device at {arpt_path}")
        else:
            if not self.model in smbios_data.smbios_dictionary:
                logging.info("No known PCI pathing for this model")
                return
            if "nForce Chipset" in smbios_data.smbios_dictionary[self.model]:
                # Nvidia chipsets all have the same path to ARPT
                arpt_path = "PciRoot(0x0)/Pci(0x15,0x0)/Pci(0x0,0x0)"
            else:
                if self.model in ("iMac7,1", "iMac8,1", "MacPro3,1", "MacBookPro4,1"):
                    arpt_path = "PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)"
                elif self.model in ("iMac13,1", "iMac13,2"):
                    arpt_path = "PciRoot(0x0)/Pci(0x1C,0x3)/Pci(0x0,0x0)"
                elif self.model in ("MacPro4,1", "MacPro5,1"):
                    arpt_path = "PciRoot(0x0)/Pci(0x1C,0x5)/Pci(0x0,0x0)"
                else:
                    # Assumes we have a laptop with Intel chipset
                    # iMac11,x-12,x also apply
                    arpt_path = "PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0)"
            logging.info(f"- Using known ARPT Path: {arpt_path}")

        if not self.constants.custom_model and self.computer.wifi and self.constants.validate is False and self.computer.wifi.country_code:
            logging.info(f"- Applying fake ID for WiFi, setting Country Code: {self.computer.wifi.country_code}")
            self.config["DeviceProperties"]["Add"][arpt_path] = {"brcmfx-country": self.computer.wifi.country_code}

For macOS compatible Atheros cards (ike the one in my iMac11,3 which uses an AR928X, as shown here), the spoof could be realized by injecting IOName into macOS via DevicePropteries. All you need is to figure out the PCI path and then add IOName: pci168c,2a.

 

Example:

 

Bildschirmfoto2023-08-09um07_41_27.png.5f1333aeaaec620767e0fb2d48c0bbbc.png

 

The PCI path of your Wifi modudle is not a fixed path! It's system-dependent! – this is only an exmaple! You can Use Hackintool to find the PCI pathof your Wifi card!

Alternatively, an SSDT could be utiliized to inject a compatible IOName into the ARPT device for OCLP to detect it as legacy WiFi Card used by Macs. Refer to the example SSDT by @deeveedee

 

To find othe potential IONames to spoof,  have a look into:  https://github.com/dortania/OpenCore-Legacy-Patcher/blob/sonoma-development/data/pci_data.py It lists alll the used IDs for Broadcom and Atheros cards already:

 

Broadcom: 

   AirPortBrcmNIC = [
        # AirPortBrcmNIC IDs
        0x43BA,  # BCM43602
        0x43A3,  # BCM4350
        0x43A0,  # BCM4360
    ]

    AirPortBrcm4360 = [
        # AirPortBrcm4360 IDs (removed duplicates for 4360 class cards)
        0x4331,  # BCM94331
        0x4353,  # BCM943224
    ]

    AirPortBrcm4331 = [
        # AirPortBrcm4331 IDs (removed duplicates for 4331 class cards)
        0x432B,  # BCM94322
    ]

    AppleAirPortBrcm43224 = [
        # AppleAirPortBrcm43224 IDs
        0x4311,  # BCM4311 - never used by Apple
        0x4312,  # BCM4311 - never used by Apple
        0x4313,  # BCM4311 - never used by Apple
        0x4318,  # BCM4318 - never used by Apple
        0x4319,  # BCM4318 - never used by Apple
        0x431A,  # Unknown - never used by Apple
        0x4320,  # BCM4306 - never used by Apple
        0x4324,  # BCM4309 - never used by Apple
        0x4325,  # BCM4306 - never used by Apple
        0x4328,  # BCM4328
        0x432C,  # BCM4322 - never used by Apple
        0x432D,  # BCM4322 - never used by Apple
    ]

Atheros: 

class atheros_ids:
    AtherosWifi = [
        # AirPortAtheros40 IDs
        0x0030,  # AR93xx
        0x002A,  # AR928X
        0x001C,  # AR242x / AR542x
        0x0023,  # AR5416 - never used by Apple
        0x0024,  # AR5418
    ]

Since the legacy Atheros card I have lives in an iMac11,3 with a non-metal GPU, I can't install Sonoma on it, so I can't test the sppof. This info is provided so others can continue to work on it.

Edited by cankiulascmnfye
  • Like 2
  • Confused 1
deeveedee
deeveedee
Posted
Posted (edited)
5 hours ago, cankiulascmnfye said:

Conditions: ACPI Name of the Wifi device in the DSDT must be ARPT. Therefore renaming the Wifi device via SSDT might be required. 

Refere to the example SSDT by @deeveedee

 

This is not true for Modern Wireless patching, which was part of the breakthrough that simplified Wi-Fi spoofing for OCLP post-install patching.  Do you mean that the Wi-Fi device must have ACPI name ARPT for legacy wireless?  My SSDT does not rename Wi-Fi to ARPT.

 

See this for accurate explanation and references.

Edited by deeveedee
cankiulascmnfye
cankiulascmnfye
Posted
Posted
4 hours ago, deeveedee said:

 

This is not true for Modern Wireless patching, which was part of the breakthrough that simplified Wi-Fi spoofing for OCLP post-install patching.  Do you mean that the Wi-Fi device must have ACPI name ARPT for legacy wireless?  My SSDT does not rename Wi-Fi to ARPT.

 

See this for accurate explanation and references.

 

See here for fully automated WifI Patching.

  • Like 1
  • Haha 4
cankiulascmnfye
cankiulascmnfye
Posted
Posted (edited)
On 8/8/2023 at 4:46 PM, deeveedee said:


There are various ways to obtain the kext.  I use OCLP to "Build and Install Open Core" and then I extract the components I need (like AmfiPass.kext) from the OC EFI that is generated by OCLP.  

 

  1. Open OCLP.  If OCLP does not detect a real Mac (as in my case, where OCLP detects "Latitude E6410"), the option to "Build and Install Open Core" will be grayed out.
      Reveal hidden contents

    1959651276_Screenshot2023-08-08at10_24_23AM.png.87aae47880988e5aa8f876e41483d8e0.png

  2. If "Build and Install Open Core" is grayed out, click "Settings" at the bottom of the OCLP Home Screen.  Choose a valid Target Model from the "Host Model" pull-down menu.  If your SMBIOS model isn't available in the pull-down menu (very likely if you have a model that is still currently supported by Apple), choose the latest model that most closely approximates your chosen SMBIOS model.  
      Reveal hidden contents

    1462597737_Screenshot2023-08-08at10_27_59AM.png.9930fa19cf31326957bfddc37caea451.png

     

  3.  Click the "Security" tab and uncheck "Disable AMFI" and uncheck "Disable Library Validation".  Look through the Extras, Advanced, Security, SMBIOS, Root Patching and App tabs to see ways that OCLP patching and the OCLP-generated EFI can be customized.  Read more here to learn more about OCLP.
      Reveal hidden contents

    641265358_Screenshot2023-08-08at10_39_46AM.png.77758b658ef7d71eaeaec36d3eac5b76.png

     

  4. Click "Return" (at the bottom of the screen) to return to the OCLP home screen
  5. Click "Build and Install Open Core" to generate an OC EFI.  Do NOT use this OCLP-generated EFI on a hackintosh.
  6. When OCLP has finished generating an OC EFI, click "View Build Log" (thanks to @cankiulascmnfye for this shortcut)
      Reveal hidden contents

    1734782462_Screenshot2023-08-08at10_36_22AM.png.47a8475844a81cf5b577105450eeee04.png

     

  7. Paste the OC build path to the OC EFI into finder and explore the OCLP-generated OC EFI.   Do NOT use this OCLP-generated EFI on a hackintosh.
      Reveal hidden contents

    2146335026_Screenshot2023-08-08at10_42_03AM.png.ea825656135396d03e7471a7387291b9.png

     

  8. You'll find AMFiPass.kext in the OC/Kexts folder.   Do NOT use this OCLP-generated EFI on a hackintosh.
  9. You can examine the OCLP-generated config.plist to confirm kext injection orders, kext patches and boot-args that you may require for your hack.

 

This guide is completeley obsolete, since AMFIPass has now been available publicly on OCLPs repositiory for about 2 weeks: https://github.com/dortania/OpenCore-Legacy-Patcher/tree/main/payloads/Kexts/Acidanthera

Edited by cankiulascmnfye
  • Sad 2
 Share
Go to topic listing
×
×
  • Create New...