Jump to content

macOS Sonoma Wireless Issues Discussion.

SavageAUS

By SavageAUS,
in LAN and Wireless

 Share
802 posts in this topic

Recommended Posts

deeveedee
deeveedee
Posted
Posted (edited)

@cankiulascmnfye You never asked for help after my Wi-Fi spoofing solution didn't work for you.  I'd be happy to help you if you post the EFI and IOReg (after booting with the non-working EFI) that didn't work for you.  Also provide the model of your Wi-Fi card.  When done properly, it works perfectly for new installations and upgrades.

 

If you would rather continue to insist that I am wrong without asking for help, you are free to do that, too.

 

The important part of my post that you quoted is "there will be a new guide posted for spoofing Wi-Fi for OCLP patching.  Until this new guide is posted ..."

Edited by deeveedee
  • Like 3
Link to comment
Share on other sites
cankiulascmnfye
cankiulascmnfye
Posted
Posted (edited)
4 hours ago, FirstTimeCustomac said:

My understanding of the boot argument is this.

 

ipc_control_port_option=0 boot-arg is needed as a workaround for Firefox and Electron apps not working when SIP and AMFI are disabled regardless of any root patches applied or not at all.

ipc_control_port_option=0 boot-arg is not needed if AMFIPass.kext is used which makes it "not a requirement" for anything.

 

Why is this boot argument "only required" for patches you describe above?

 

It affects metal-related tasks, not Wifi, that's why. If you want to patch Wifi, it's not needed as part of a guide. If you want to install macOS Sonoma on unsupported hardware – which requires iGPU/GPU patching – then it's required. But that's not part of his guide, is it?. BTW, I covered preparing Wintel systems for installing Ventura and newer in-depth already. It took a lot of time and research:  https://github.com/5T33Z0/OC-Little-Translated/tree/main/14_OCLP_Wintel

 

3 hours ago, Matgen84 said:

 

I don't disable AMFI to apply root patches with OCLP, for Nvidia Kepler Card and Intel HD 4000 (Ivybridge, SMBIOS Macpro6,1, Monterey 12.6.8). All works fine.

 

No you don't. Disabling SIP is MANDATORY for running a system with patched-in NVIDIA drivers to boot. Once SIP is disabled. AMFI doesn't work any more. AMFI depends on SIP BEEING ENABLED. That's another thing AMFIPass does: it tells apps that require AMFI "everything is fine" even if it is not.

Edited by cankiulascmnfye
  • Like 2
Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted (edited)
53 minutes ago, cankiulascmnfye said:

No you don't. Disabling SIP is MANDATORY for running a system with patched-in NVIDIA drivers to boot. Once SIP is disabled. AMFI doesn't work any more. AMFI depends on SIP BEEING ENABLED. That's another thing AMFIPass does: it tells apps that require AMFI "everything is fine" even if it is not.

 

If you read my post: I don't talking about SIP.
 

Spoiler

I don't disable AMFI to apply root patches with OCLP, for Nvidia Kepler Card and Intel HD 4000 (Ivybridge, SMBIOS Macpro6,1, Monterey 12.6.8). All works fine.

 

Sorry for Off Topic: "For Intel HD 4000 users, you may have noticed that SIP is partially disabled. This is to ensure full compatibility with macOS Monterey" OCLP documentation. OCLP offers to use 0x803.

 

But for Sonoma, I can re-enable SIP under Patcher Settings. And using AMFIPass. Right ? Let me now. I don't understand well.

 

Sorry again for my bad English.

Edited by Matgen84
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Not needed to change back and forth SIP. Just choose once a value for "Third party kexts allowed" and "Not Apple internal". Some application needed "Unrestricted file system".

  • Like 3
Link to comment
Share on other sites
cankiulascmnfye
cankiulascmnfye
Posted
Posted
5 minutes ago, Slice said:

Not needed to change back and forth SIP. Just choose once a value for "Third party kexts allowed" and "Not Apple internal". Some application needed "Unrestricted file system".

 

There is no flag call "Not Apple Internal". There only is "Allow Apple Internal".  If "Allow Unauthenticated Root" isn't set, OpenCore Legacy Patcher can't apply GPU patches. Try for yourself.

 

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

"Allow Apple Internal" = 1 so "Not Apple Internal" = 0 :wink_anim:

Agree about "Allow Unauthenticated Root"

 

I also use "Device configuration" and "Allow unapproved kexts"

  • Like 2
Link to comment
Share on other sites
FirstTimeCustomac
FirstTimeCustomac
Posted
Posted
2 hours ago, cankiulascmnfye said:

If you want to install macOS Sonoma on unsupported hardware – which requires iGPU/GPU patching – then it's required. But that's not part of his guide, is it?

My question is, is it required for these apps once you disable SIP and AMFI regardless of any root patches applied or not? It seems like you are saying that the boot argument it only required for iGPU/GPU patches.

 

What if I have SIP/AMFI disabled with WIFI patching? Would I need the boot argument for those apps?

Link to comment
Share on other sites
cankiulascmnfye
cankiulascmnfye
Posted
Posted
1 minute ago, FirstTimeCustomac said:

My question is, is it required for these apps once you disable SIP and AMFI regardless of any root patches applied or not? It seems like you are saying that the boot argument it only required for iGPU/GPU patches.

 

What if I have SIP/AMFI disabled with WIFI patching? Would I need the boot argument for those apps?

 

ipc_control_port_option=0  Is only required on systems that need iGPU/dGPU patching so that the aforementioned apps don't crash. It's graphics/metal-related and has nothing to do with Wifi, AMFI or SIP. If your system doesn't require root patches for iGPU/dGPU you don't need it.

 

Affected systems: 1st to 6th Gen Intel Core with iGPUs and/or Legacy GPUs

 

 

 

 

  • Like 1
Link to comment
Share on other sites
FirstTimeCustomac
FirstTimeCustomac
Posted
Posted
6 minutes ago, cankiulascmnfye said:

ipc_control_port_option=0  Is only required on systems that need iGPU/dGPU patching so that the aforementioned apps don't crash. It's graphics/metal-related and has nothing to do with Wifi, AMFI or SIP. If your system doesn't require root patches for iGPU/dGPU you don't need it.

Whether I need the iGPU/dGPU patches or not, is it true that "If SIP/AMFI are disabled" regardless of any root patches, the boot argument is required so the aforementioned apps don't crash?

Link to comment
Share on other sites
cankiulascmnfye
cankiulascmnfye
Posted
Posted
17 minutes ago, FirstTimeCustomac said:

Whether I need the iGPU/dGPU patches or not, is it true that "If SIP/AMFI are disabled" regardless of any root patches, the boot argument is required so the aforementioned apps don't crash?

 

Check the Source Code:

 

Quote

 if self.constants.sip_status is False or self.constants.custom_sip_value:
            # Work-around 12.3 bug where Electron apps no longer launch with SIP lowered
            # Unknown whether this is intended behavior or not, revisit with 12.4

 

https://github.com/dortania/OpenCore-Legacy-Patcher/blob/e8ee2a2657c4d37de8c8619541c2b314cf6b6371/resources/build/security.py#L33C1-L33C1

  • Like 1
Link to comment
Share on other sites
Cyberdevs
Cyberdevs
Posted
Posted

@FirstTimeCustomac

As far as OCLP and SIP are concerned you need three flags to be set for the root patches (030800000) to work, anything beyond that might not work with OCLP but you can test csr-active-config=030C or 030C0000 value and see if that works with your apps or not.

This is the initial flags require for OCLP to work with addition of ALLOW_EXECUTABLE_POLICY_OVERRIDE

 

I'm not sure if it's gonna work but it's worth to try.

  • Like 2
Link to comment
Share on other sites
cankiulascmnfye
cankiulascmnfye
Posted
Posted (edited)

Regarding Legacy Wifi patching

 

Additiional Kext Requirements:

  • corecaptureElCap.kext
  • IO80211ElCap.kext
    • Contaiins a Plugin-Kext: AirPortAtheros40

Available here: https://github.com/dortania/OpenCore-Legacy-Patcher/tree/main/payloads/Kexts/Wifi  (The other 2 in that folder are for "Modern" Wifi Cards)

 

UPDATE:

  • For Legacy Atheros Wifi Cards, ONLY these 3 of these kexts are required. No doubt about it since I need those on my iMac11,3 for the Atheros Card it has.
  • For Legacy Brcm Cards I am uncertain if IOSkylwalk etc are required as well. From the Look of things it doesn't seem to be the case. I need to find a Mac model in the list that uses legacy brcm Wifi in order to realyl tell.

 

 

 

Edited by cankiulascmnfye
  • Like 3
Link to comment
Share on other sites
FirstTimeCustomac
FirstTimeCustomac
Posted
Posted

Thanks @Cyberdevs

 

For Monterey, I did not need AMFI disabled for OCLP to apply Nvidia Kepler patch unlike the claim from the previous post.

 

For Sonoma,  I needed ipc_control_port_option=0 boot-arg when I first applied Modern Wireless patch to prevent Firefox from crashing because AMFI had to be disabled as suggested in Hackintosh note in that Sonoma PR. Because AMFIPass.kext did not work with the initial preview build of OCLP for Sonoma.

 

For Ventura and Sonoma, with AMFIPass.kext, I do not require ipc_control_port_option=0 for any of my root patches applied including Nvidia Kepler patch . Firefox works as intended as AMFI did not have to be disabled.

 

For me, usage of ipc_control_port_option=0 boot-arg comes down to whether the SIP/AMFI are disabled for any reason and not just iGPU/dGPU root patched system.

 

Also, I'd like to know exactly which OCLP root patches still require AMFI to be disabled even with AMFIPass.kext injected. Sorry if I am asking too many questions.

Link to comment
Share on other sites
Cyberdevs
Cyberdevs
Posted
Posted

@FirstTimeCustomac

AFIAK yes, for macOS Sonoma it is required to disable AMFI and SIP for root patches to work so if you are going to use AMFIPass.kext you need to use -amfipassbeta boot-arg otherwise it won't work. So you either need to use the kext or set amfi=0x80 older versions of macOS didn't require AMFI to be disabled.

  • Like 3
Link to comment
Share on other sites
jsl2000
jsl2000
Posted
Posted (edited)
On 8/11/2023 at 7:34 PM, deeveedee said:

@cankiulascmnfye You never asked for help after my Wi-Fi spoofing solution didn't work for you.  I'd be happy to help you if you post the EFI and IOReg (after booting with the non-working EFI) that didn't work for you.  Also provide the model of your Wi-Fi card.  When done properly, it works perfectly for new installations and upgrades.

 

If you would rather continue to insist that I am wrong without asking for help, you are free to do that, too.

 

The important part of my post that you quoted is "there will be a new guide posted for spoofing Wi-Fi for OCLP patching.  Until this new guide is posted ..."

Thanks for your king help and instruction of the method for spoof IOName of BCM4352 WiFi adapter.

Can you take a look at my EFI of OC 0.9.4 why my DeviceProperties unable to spoof it correctly even I can spoof XHC's IOName for comparison ?

Screen Shot 2023-08-12 at 14.29.14.png

EFI.zip

Screen Shot 2023-08-12 at 14.50.54.png

Edited by jsl2000
Link to comment
Share on other sites
jsl2000
jsl2000
Posted
Posted (edited)
16 minutes ago, cankiulascmnfye said:

@jsl2000 Disable AirportBrcm4360_injector.kext.

Thanks for your link for detailed instruction, but its MaxKernel is 19.9.9 which's not related to this issue

Edited by jsl2000
Link to comment
Share on other sites
cankiulascmnfye
cankiulascmnfye
Posted
Posted (edited)
32 minutes ago, jsl2000 said:

Thanks, but its MinKernel is 19.9.9 which's not related to this issue

 

You meant MaxKernel…

 

Your PCI path looks unsually long and has many sub-levels but the IOReg entry looks correct. Xhci is only relevant for Bluetooth. 

 

I am not the one promoting the IOName spoofing method (since I think it is unreliable) so I can't help you.

Edited by cankiulascmnfye
  • Like 1
Link to comment
Share on other sites
cankiulascmnfye
cankiulascmnfye
Posted
Posted (edited)
1 hour ago, FirstTimeCustomac said:

I think you should really ask @deeveedee or @Stefanalmare for help if your having hard time getting it to work.

 

 

 

I fixed this days ago on thursday by using a modified version of OCLP! I updated the instructions.

It was me who pointed towards that simply adding kexts wouldn't be enough

Then @acquarius13 found the switch for force-enabling Wifi patching

From then on, I focussed on working with a patched OCLP from the Sonoma Branch while deeveedee focused on a DevProps spoof

By now I've also figured out which kexts are needed for re-enabling Legacy Wifi as well

So as far as using a custom build of OCLP for applying root patches to re-enable Wfi is concerned, it's a wrap! I am pretty sure that the official release of the patcher for Sonoma will have an option in the GUI to enable Wifi patching so it won't be a requirement to spoof a compatible device nor compile a custom version of OCLP to re-enable Wifi.

 

Edited by cankiulascmnfye
  • Like 2
Link to comment
Share on other sites
FirstTimeCustomac
FirstTimeCustomac
Posted
Posted (edited)
6 hours ago, cankiulascmnfye said:

It was me who pointed towards that simply adding kexts wouldn't be enough

You mean pointed this to OCLP devs? I am not sure if understand the point of this.

 

6 hours ago, cankiulascmnfye said:

thursday 

By the way, with a quick peek at your writing, you seem to mention about the -amfipassbeta but I don't see any mention of injection of AMFIPass.kext with the boot argument. Just in case if you didn't know, -amfipassbeta itself does not do anything by itself and it does not replace AMFIPass.kext. FYI, you can also use -liubetaall instead of -amfipassbeta and no need to add -amfipassbeta if you already have -lilubetaall in your boot-args

 

Please explain, how does adding -amfipassbeta boot flag as an option fixes not working wifi after applying the root patches in Sonoma especially when you already have added amfi=0x80 in boot-args? Or did you just copy and paste what others were posting on this forum? Adding amfi=0x80 is not required for applying root patches for wifi as you say in your writing, not if you are injecting AMFIPass.kext, -amfipassbeta and use the latest nightly build of sonoma-development branch. 

 

6 hours ago, cankiulascmnfye said:

I've also figured out which kexts are needed for re-enabling Legacy Wifi as well

OK. Good job. I am sure it will helps many!

Edited by FirstTimeCustomac
Link to comment
Share on other sites
marsuss
marsuss
Posted
Posted
On 8/11/2023 at 12:17 PM, CloverLeaf said:

 

I did nothing, Apple did 🙃 Beta 4 was bad in terms of battery life for me. I am using the same config and now with Beta 5 the battery works just fine. It's not a new battery, but I still get 4:30-5 hours with 70% brightness. Same in Windows 11.

 

 

EDIT: Writing from my phone I posted in the wrong section. This info shouldn't be in Sonoma Wireless discussion but in the main MacOS Sonoma thread. Sorry. Mods can move my posts there.

mine is getting max 2hrs... I've tried everything but still 2hrs.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...