Jump to content
373 posts in this topic

Recommended Posts

Doing exactly what @KGP-iMacPro describes in the first post, I have working wifi with the Fenvi T919 on Tahoe 26.1.

Performance seems to be the same of Sequoia, Sonoma or Ventura.

It's surprising how easy it's been.

Tahoe's start-up times haven't changed.

 

EDIT: -amfipassbeta with AMFIPass.kext doesn't work, kernel panic at boot.

 

 

Edited by miliuco
info
  • Like 5
  • Thanks 1

AMFIPass.kext can no longer bypass AMFI.kext correctly on macOS Tahoe.

 

Although I have self-signed the binary file, it still causes AMFI to block the system.

 

image.thumb.png.155f3458aff1df28a159c1bd2dcc2e90.png

  • Like 5
  • Thanks 1
Just now, deeveedee said:

@laobamac_yyds Are you affiliated with the OCLP fork posted in this thread?

No.

Because this patch will destroy AMFI, causing WeChat, Quark and other apps to be unavailable, I did not merge it into OCLP-Mod.

And the current old version of IOSkywalkFamily will cause the crash and restart of some platforms, and we still need to wait for ACDT to fix the compatibility problem.

  • Like 5
  • Thanks 1

Say something off-topic.

 

I still think that this branch should not be widely promoted. EduCovas has never publicly released the OCLP that "supports macOS 26". We should wait for the new version of AMFIPass.kext and IOSkywalkFamily, instead of using an unstable self-compilation  branch.

 

And the App and PSPKG used by this branch have not been signed in any way.

 

I don't mean anything else. All the work of developers is meaningful, just to express my personal thoughts.

Edited by laobamac_yyds
  • Like 4

The known problem now is:

1. In some cases, WiFi cannot be connected automatically (such as after waking up from sleep)

2. The probability of expanding the screen has no signal

3. After switching on and off the WiFi switch many times, the probability will lead to the inability to connect to the network.

 

However, the basic iServices and network functions have been implemented. All we need is a Tahoe-compatible AMFIPass to allow macOS to load self-signed binary files, and we can include it in the Pre-release of OCLP-Mod in advance for a few " Adventurer" was used.

After all, the consequences of destroying AMFI are too great. After losing TCC, even the pop-up window of App application authority has disappeared. I don't think I will choose amfi=0x80 unless I have a last resort.

  • Like 6

Why don't people who are against using this unapproved OCLP create another thread and leave this one clean?

I don't want to upset anyone, but is it possible that those who are using this OCLP are aware of the risks without being complete idiots?

@fabiosun This thread's title is going to get confusing when the official OCLP 3.0.0 is released.  Why can't this thread be renamed to avoid the ambiguity and the first post edited to make sure people know this is an experimental fork that is not developed by OCLP devs and not by laobamac_yyds?

 

The reason that I am contributing to this thread is because of the way the thread was created. I'm not trying to thwart experimentation.

 

37 minutes ago, laobamac_yyds said:

After all, the consequences of destroying AMFI are too great. After losing TCC, even the pop-up window of App application authority has disappeared. I don't think I will choose amfi=0x80 unless I have a last resort.

Agreed.

 

EDIT: @KGP-iMacPro Thank you for renaming this thread and for your cautionary note at the beginning of the first post.  You may also want to include links to laobamac's warnings here and here in the first post with your cautionary note.

 

Edited by deeveedee
  • Like 2

this is correct...but you and other are saying this from a bit..and people could build their idea 

then if the title of this thread is "the problem" i hope the creator could modify it accordly.

 

 

  • Like 2

@deeveedee, I finally changed the title of the thread and put a warning just right at the beginning. If you are still not content with the change, feel free to propose something else. 👍  

  • Like 1
  • Thanks 1

laobamac is the authority on this topic, not me.  You may want to include links to laobamac's warnings here and here with your cautionary note in the first post.

Edited by deeveedee
  • Confused 1
3 minutes ago, KGP-iMacPro said:

This is starting to get really annoying. Should I just delete this thread? @laobamac_yyds

Well,my friend,we are just discussing issues, there's no need to be so serious.

 

Perhaps the atmosphere of the topic is temporarily unpleasant But I think it's just occasional, it's not enough to reach the point where the post needs to be deleted.

 

Best regards.

  • Like 4

From my point of view, the thread now has a very comprehensive title.
Incidentally, the author of this fork is not completely unknown in the Hackintosh world.
Perhaps the moderators at insanelymac could clean up this thread of irrelevant messages to make it easier to read for those who (knowingly) decide to try it. 

  • Like 1
4 minutes ago, laobamac_yyds said:

Well,my friend,we are just discussing issues, there's no need to be so serious.

 

Perhaps the atmosphere of the topic is temporarily unpleasant But I think it's just occasional, it's not enough to reach the point where the post needs to be deleted.

 

Best regards.

 

Absolutely no problem my friend. I know you are just providing facts and try to help whenever possible. I am more than open for any changes or advises. However, there is another person, just permanently complaining. 🤔

  • Sad 1
23 minutes ago, fabiosun said:

Perhaps the moderators at insanelymac could clean up this thread of irrelevant messages to make it easier to read for those who (knowingly) decide to try it. 

Moderators can certainly delete my posts.  Please do not delete laobamac's important posts here and here and here.

Edited by deeveedee

Alright, my friends, don't dwell on this issue anymore. Just treat it as a small interlude.

 

On the weekend, I will try using Lilu to hook the part of verifying code signatures in AppleMobileFileIntegrity. kext to see if it can allow self signed certificates, which can ensure that other security policies are not affected.I don't know if it will succeed, but how can I know without trying.😃

 

Good night (China time, haha)

  • Like 5

@deeveedee

before the creation of amfipass.kext...we all used amfi=0x80 bootarg

So for this, for people using OCLP it is not a new subject/threat 

You were right about the title.

Now leave the others join more simply this thread, and no offence i hope for you in this :)

 

40 minutes ago, KGP-iMacPro said:

This is starting to get really annoying. Should I just delete this thread? @laobamac_yyds

 

I don't see any reason to delete this thread. Quite the opposite, this thread should be pinned and highlighted in bold.

You’re only trying to help. You’ve already renamed the topic and the necessary warnings are clearly stated. We all know everyone is eagerly waiting for the developers and the official OCLP release.

In the meantime, community members like you, @laobamac_yyds, are stepping up to help. We should be grateful for that.

If anyone is hesitant to try this fix, there’s no need to worry. People like @eSaF and myself will be here to test whatever comes forward.

Go for it, my friend—full power ahead.

Edited by Irish_Man
  • Like 5

Yes - don't delete this thread.  The new title and clear messaging in the first post, along with contributions from laobamac_yyds, make this a very informative thread.  Definitely worthy of experimentation.

  • Like 1

This process is working for me. I am grateful to not have an antenna sticking out of my laptop.  I haven't encountered any problems with amfi=0x80 yet but I recall having problems with some apps before the amfipass.kext came out.  It seems that we are heading in the right direction and this is a good alternative to USB-WiFi.'

 

In the meantime, I wanted to add that, before I installed these root patches, I reverted the root patches from OCLP-Mod, uninstalled the OCLP-Mod app, and deleted VoodooHDA.kext from Library/Extensions before running these root patches.  (I don't know but I really liked VoodooHDA).  Be sure not to have VoodooHDA and AppleALC both loading.

 

EDIT:  Well, that was fast.  Because of the amfi=0x80 bootarg, I cannot use Parallels, which I use for my work.  Thus, until that is resolved, I have to choose between having Broadcom WiFi and being able to work on my laptop.  Of course, it's not really a choice.  So I am reverting back to USB WiFi for now but am glad to see real progress in restoring Broadcom WiFi functionality. I am hoping that can be resolved by an update to AMFIPass.kext. 

Edited by mnfesq
  • Like 3
  • Thanks 1
×
×
  • Create New...