macOS Sonoma Wireless Issues Discussion.

[surenmunoo]

5 hours ago, kinhhoang161 said:

EDIT: 1

i try edit sys_patch_detect.py > self.legacy_wifi = True and rebuild OCLP again and althought it show available patches for your system but i still cant start root patching because unsupported host OS 

I went through that same issues but did a new Sonoma install booting with my regular EFI that is use for Ventura, then followed @deeveedeerecommendations and built a EFI using OCLP in Sonoma, copied my regular EFI to USB and configure it in USB and tried it to boot Ventura, once I got that working properly, I booted with edited EFI into Sonoma and did the patch, reboot and its working. I used the EFI generated by OCLP only as a reference for kext order etc. 

Edited July 30, 2023 by surenmunoo

[cankiulascmnfye]

So, on my T490 Laptop I had Ventura and Sonoma on 2 different volumes booting from the same EFI. Everything was working great. So I decided to Upgrade Venture to the public beta of Sonoma and kill the Volume with the Sonoma Dev build. And after that Intel Wifi stops working after about half a minute or so. So I updated AirpritItlwm from  https://github.com/OpenIntelWireless/itlwm/issues/883  but the issue remains- I will never do incremental upgrades again. Goddamn Sonoma BS.

 

EDIT: I forgot to update Little Snitch to the preview version of Sonoma after the upgrade so it just blocked all the traffic. Now everything's back to normal again

Edited July 30, 2023 by cankiulascmnfye

[Max.1974]

Im notice that my Lenovo E470 Thinkpad was working everything with your help and OCLP 0.6.9 

 

Recognize all devices and Airdrop back and send

 

[deeveedee]

21 hours ago, kinhhoang161 said:

@deeveedee thank you, I'm still redoing the steps you did earlier. I look forward to your confirmation of the steps..

 

I am glad that you asked me to confirm my installation steps.  It turns out the the steps that I thought were unnecessary for my hack (the steps with a strike-through here)  are actually necessary for post-install patching but are not necessary for normal Wi-Fi operation (after patching).  If my config.plist does not include a binary rename of PXSX -> ARPT or it does not include spoofing the Wi-Fi device that is in a real MBP6,2 ("pci14e4,4353"), the OCLP 0.6.9 post-install patcher does not recognize my Legacy Wi-Fi to be patched.  The reason that I thought this was unnecessary is that after the Wi-Fi patches are applied, the binary rename and device spoofing are NOT required for normal Wi-Fi operation.  The spoofing is only required for patching.  Sorry I'm repeating myself, but this "before and after patching" behavior is important.

 

After performing a clean installation of Sonoma 14.0 Beta 4, I attempted to apply post-install patches with OCLP 0.6.9 (nightly build downloaded on 07/30/2023).  If my config.plist did not include a binary rename of PXSX -> ARPT or spoofing "pci14e4,4353" (the Wi-Fi device in a real MBP6,2), post-install patching did not recognize my Wi-Fi as needing to be patched:

Spoiler

 

If I modified my config.plist to include the PXSX -> ARPT binary rename and spoofing "pci14e4,4353", the post-install patcher recognized my Wi-Fi as needing to be patched:

Spoiler

 

If my config.plist included only the binary rename PXSX -> ARPT or only the device spoofing to "pci14e4,4353", the post-install patcher did not recognize my Wi-Fi as needing to be patched.  BOTH ACPI patches were required for me.

 

Attached are my SSDT-ARPT (to spoof the MBP6,2 Wi-Fi device) and a sample config.plist that includes the elements that I required in my config.plist to apply legacy Wi-Fi post-install patches.

 

IMPORTANT: I cannot post a "universal" SSDT-ARPT and a binary rename (PXSX -> ARPT) that works on all PCs, because different PCs have different ACPI device paths and device names.  You will need to customize my ACPI patches to spoof the BCM 94352HMB Wi-Fi on your PC.

 

NOTE: I performed my clean Sonoma installation and post-install patching with AMFI and Library Validation fully enabled (no amfi=0x80 boot-arg, no AMFI or LV kernel patches).  AMFIPass.kext 1.3.1 with boot-arg -amfipassbeta was all I needed.

 

NOTE: After post-install Wi-Fi patches are applied, device spoofing is no longer necessary and can be disabled/removed in config.plist.  My BCM 94352HMB Wi-Fi works fine in Sonoma without the device spoofing after the patches are applied.

 

SSDT-ARPT.aml.zip config-sonoma-patch-sample.plist.zip

Edited July 31, 2023 by deeveedee

[deeveedee]

Well, I need to admit to one of my more public F'ups.   It appears that the "new" AirportBrcmFixup.kext included with OCLP 0.6.9 is not the reason that Wi-Fi works on my HackBookPro6,2 in macOS Sonoma.  @ThriftLover and @emax31 were on the right track by suggesting that the AirportBrcmFixup.kext change was only the removal of an unused plugin. The before patching and after patching behavior of my Wi-Fi (explained in my previous post) is the true reason that Wi-Fi now works for me in Sonoma with my BCM 94352HMB on my old Dell Latitude E6410 (SMBIOS MBP6,2).  I was experimenting with device spoofing (via ACPI patches) and different versions of AirportBrcmFixup.kext at the same time and did not recognize that it was the spoofing that resulted in a successful application of post-install legacy Wi-Fi patches, not the AirportBrcmFixup.kext version.

 

I apologize for my confusion and hope that my revelation helps others to get Wi-Fi working in Sonoma on their legacy hacks.  I have successfully been able to repeat a clean installation of Sonoma, post-install Wi-Fi patching with OCLP 0.6.9 and my Wi-Fi is working perfectly in Sonoma Beta 4.

 

Once OCLP 0.6.9 post-install patches are applied (which requires the Wi-Fi device spoofing on my old legacy hack with BCM 94352HMB), the Acidanthera version of AirportBrcmFixup.kext 2.1.7 works fine in Sonoma.

 

EDIT: Others may prefer to modify OCLP to apply post-install patches (instead of spoofing Wi-fi).  You'll see that I started to do this here.  I'm content with my Wi-Fi spoofing (ACPI patch) approach, but if you want to modify OCLP, hopefully my initial attempt here helps.

Edited July 31, 2023 by deeveedee

[cankiulascmnfye]

@deeveedee Nice find. I will test this later since I have a BCM94352 as well.

 

Notes on your SSDT: it can be optimized, so you don't need any binary rename: change the form of the SSDT: If OSI = Darwin: disable PSXS, add ARPT. I think this is the cleanest implementation. Example: https://github.com/pupboss/Hackintosh/blob/master/CLOVER/ACPI/patched/SSDT-ARPT.dsl (needs If OSI Darwin still)

Alternatively: Use a binary rename to rename the device system wide and use device properties add the compatible device-id etc. Pros: relatively easy, changing the device-id property only affect macOS. Cons: ACPI Rename might affect WIFI in Windows.

 

But I am baffled to why the rename is required on Wintel systems. Here are my "specualtions".

 

If your run OCLP on a real Mac,  (I guess) the patcher does the following:

1. Dectects the WiFI device (ARPT)
2. Checks the deviceID of the wifi card to figure out the vendor and model
3. Depending on the rules defined for the Mac Model (or the detected card, or both?), it adds the required kexts to re-enable Wifi to the EFI and config (a look into the source code might help to clarify)
4. It then applies the root patches. Which ones? I don't know! Maybe the patch log will provide clues.
5. Reboot Mac. Hooray, working Wifi

Now my speculations on what  happens in this case when running OCLP on Wintel systems instead:

• It detects AirportBrcmPatchRAM (which handles the renaming to ARPT on Hack, btw) is already present
• It then goes: "Hey, AirportBrcmPatchRAM is already present on this Mac – must be patched already, nothing to do here"

If you have a look at the complete config of OCLP (located at https://github.com/dortania/OpenCore-Legacy-Patcher/blob/main/payloads/Config/config.plist), you will notice that it can inject various kexts for Wifi devices (check the comments):

 

 

NOTE: The prefixes mentioning older versions of macOS indicate the origin of the kext (where they are from – not the OS they are for).
 

Possible approach/test for PC Users: treat her like  a real Mac – in other words:

• Add a PSXS to ARP Rename
• Disable all the Wifi kexts (these don't exist on real Macs either)
• Run OCLP, see if it apply the patches
• Add/enable the required kexts
• Reboot

>> Iv'e tested this, it doesn't work for me.

 

Edited July 31, 2023 by cankiulascmnfye

[deeveedee]

@cankiulascmnfye I like it! My ACPI patch is only temporary (used only for post-install patches and not during normal ops) so I'm not too concerned about its optimization or conditional (Darwin) application, but I like your suggestion better than mine.

Edited July 31, 2023 by deeveedee

[cankiulascmnfye]

For me this method doesn't work yet, because my DSDT does not contain an PSXS Device that I could rename. Adding the SSDT didn't have any effect either.

 

If it's only about the device-id (or device-id spootf), injecting the wifi card via device properties might be an option as well.

Edited July 31, 2023 by cankiulascmnfye

[Max.1974]

Hi Guys, great effort here from you

 

Congrats 

 

If help someone my Broadcom Card from Lenovo is this, and work fine with OCLP 0.6.9 Rooting Patcher

 

 

 

 

 

But on Hackintool shows up pci14e4,43a0, im think is because my DSDT was edited by @MaLd0n and works fine like always!! 

 

Im not use SSDT, just DSDT since 2018

 

 

 

 

 

 

 

[SavageAUS]

This may be off topic not sure.
I’m using the OCLP patcher posted in the dummies guide thread and it is offering me to update OCLP. Should I do it? Are the modern wireless patches mainline?


Sent from my iPhone using Tapatalk

[cankiulascmnfye]

1 hour ago, SavageAUS said:

This may be off topic not sure.
I’m using the OCLP patcher posted in the dummies guide thread and it is offering me to update OCLP. Should I do it? Are the modern wireless patches mainline?


Sent from my iPhone using Tapatalk

 

2-part answer: updatin: Yes.

Wireless patches included: No. If the update is 0.6.8 from the master branch of the repo, then it has no sonoma patches. As mentioned often before, you need the nightly build of 0.6.9: https://nightly.link/dortania/OpenCore-Legacy-Patcher/workflows/build-app-wxpython/sonoma-development/OpenCore-Patcher.app (GUI).zip

Edited July 31, 2023 by cankiulascmnfye

[cankiulascmnfye]

On 7/28/2023 at 3:57 PM, Blesh said:

Has anyone else experienced this issue? My WiFi is working and showing available networks, but even after connecting, I still can't access the internet. Any suggestions on how to fix this?

 

YES. Do you use Little Snitch? If you upgraded from Ventura or older, you need to update to the preview version of Little Snitch for Sonoma. Get it from their website!

[deeveedee]

7 hours ago, cankiulascmnfye said:

For me this method doesn't work yet, because my DSDT does not contain an PSXS Device that I could rename. Adding the SSDT didn't have any effect either.

 

If it's only about the device-id (or device-id spootf), injecting the wifi card via device properties might be an option as well.

When you boot Ventura with patched / working Wi-Fi (with your BCM 94352HMB), what is your ARPT ACPI  path as shown in IOReg Explore?    It is impossible for me to post a "universal" SSDT, because different PCs have different ACPI device paths and device names.

 

Here's what mine looks like:

Spoiler

 

Edited July 31, 2023 by deeveedee

[deeveedee]

4 hours ago, Max.1974 said:

Hi Guys, great effort here from you

 

Congrats 

 

If help someone my Broadcom Card from Lenovo is this, and work fine with OCLP 0.6.9 Rooting Patcher

 

But on Hackintool shows up pci14e4,43a0, im think is because my DSDT was edited by @MaLd0n and works fine like always!! 

 

Im not use SSDT, just DSDT since 2018

 

That's why MaLd0n is one of the hackintosh Masters.  He is/was always focused on the "Vanilla" hackintosh.

Edited July 31, 2023 by deeveedee

[cankiulascmnfye]

6 minutes ago, deeveedee said:

 

That's why MaLd0n is one of the hackintosh Masters.  He is/was always focused on the "Vanilla" hackintosh.

 

Well, in this case, it's because of wht AirportBrcmFixup injected – not what's in the DSDT… so this credit goes to Acidanthera

Edited July 31, 2023 by cankiulascmnfye

[deeveedee]

6 minutes ago, cankiulascmnfye said:

 

Well, in this case, it's because of wht AirportBrcmFixup injected – not what's in the DSDT… so this credit goes to Acidanthera

OCLP 0.6.9 won't patch my BCM 94352HMB Wi-Fi if ACPI does not match that of a real MBP6,2.  AirportBrcmFixup does not do this (for me).  I must patch ACPI for OCLP patcher to recognize my Wi-Fi for patching.

 

If you post the ACPI path for your BCM 94352HMB Wi-Fi (as shown in IOReg in Ventura as I show here), I should be able to tell you what to patch.

Edited July 31, 2023 by deeveedee

[cankiulascmnfye]

@deeveedee Is your inbox full?

[deeveedee]

Just now, cankiulascmnfye said:

@deeveedee Is your inbox full?

Quite possibly.  There is a lot of stuff in it that I need to delete.

[hoaug]

17 hours ago, surenmunoo said:

I went through that same issues but did a new Sonoma install booting with my regular EFI that is use for Ventura, then followed @deeveedeerecommendations and built a EFI using OCLP in Sonoma, copied my regular EFI to USB and configure it in USB and tried it to boot Ventura, once I got that working properly, I booted with edited EFI into Sonoma and did the patch, reboot and its working. I used the EFI generated by OCLP only as a reference for kext order etc. 

 

i also use EFI of OCLP, idk why it doesnt working @@

[SavageAUS]

Might be a dumb question. But can any of this root patching etc effect any other os?
I have Archlinux installed on the same system (different ssd) and my WiFi is stopping arch from loading. If I disable the wifi card in the bios I can boot into arch. I’ve tried a fresh install in case it was me but as soon as I load the drivers for the Broadcom 4360 I cannot boot anymore.
Coincidence or ?

I’m going to try Manjaro and see if it gets the same results.


Sent from my iPhone using Tapatalk

[deeveedee]

2 hours ago, kinhhoang161 said:

 

i also use EFI of OCLP, idk why it doesnt working @@

OCLP's EFI can only be used as a reference on a hackintosh. You cannot use OCLP's EFI on a hackintosh. Please re-read my posts.

[hoaug]

@deeveedee i just config like config-sonoma-patch-sample.plist. did i do it wrong? and I don't know why I lost my ethernet

[deeveedee]

9 minutes ago, kinhhoang161 said:

@deeveedee i just config like config-sonoma-patch-sample.plist. did i do it wrong? and I don't know why I lost my ethernet

 

We have different PCs, so you can use my posted examples with the understanding that my solution works on a Dell Latitude E6410 with BCM 94352HMB Wi-Fi. The basic idea of what I posted is that the OCLP 0.6.9 wi-fi patcher is looking for a real Mac, so you need to spoof the wi-fi device or modify OCLP python for OCLP post-install patches.  Once the OCLP patches are applied, remove the ACPI patch.

Edited July 31, 2023 by deeveedee

[deeveedee]

I am so paranoid about providing misinformation about Sonoma installation/patching that I performed yet another clean installation of Sonoma.  I have confirmed that on my hack, I MUST spoof Wi-Fi (PXSX->ARPT and device name) in order for OCLP 0.6.9 to detect my BCM 94352HMB for patching.  See here for my exact steps and files that I used to perform a clean installation of Sonoma on my HackBookPro6,2.  You may need to adapt my steps and files to your hack unless your PC is a Dell Latitude E6410 (Nvidia) with BCM 94352HMB Wi-Fi.  If you don't want to spoof Wi-Fi via ACPI patches, then you should be able to modify OCLP as I described here. I am content with Wi-Fi spoofing (since it is temporary and needed only for OCLP patching), so I don't plan to pursue OCLP mods.

Edited July 31, 2023 by deeveedee

[Max.1974]

12 hours ago, deeveedee said:

 

That's why MaLd0n is one of the hackintosh Masters.  He is/was always focused on the "Vanilla" hackintosh.

 

Certainly my brother, he is first of all humble enough to give us unconditional help, like most of us here, and if there is a conflict that he cannot solve, he is happy to see that other methods help too. I know that my DSDT needed to be injected both wirelessly and my Lenovo IBM keyboard, via another GitHub coder friend, Rafael Armênio, both of whom were kind enough to help us out. I'm sure that friendship, above all, must remain, and even more, his ability and competence. The Opencore team has every possible merit except teaching us how to compile DSDT. This is attributed only to some users who deal more or less with SSDT. And so many others who are gone like Rehabman for example. Without union and without humility, no one leaves the place.