kein platz für fenvi.......

Die nicht nativen (DW1550, DW1560) gehen inzwischen auch da ist auch nicht viel Magie dabei...

Am langen Ende ist es eine Frage der richtigen Reihenfolge der Extensions denn das eine bedingt mitunter das andere und umgekehrt...

Zweifelsfrei muss die IOSkywalkFamily.kext als erste geladen werden die ist die Basis für alles weitere als nächstes dann AirportBrcmFixup.kext (nur die nicht den Injector der wird nicht benötigt) und zu guter Letzt die IO80211LegacyFamily.kext und Ihr Plugin. Damit sollte seitens der Extensions alles erledigt sein und von der Reihenfolge her sollte es passen. Im nächsten Step muss dann ggf. einmalig das BootArg amfi=0x80 gesetzt werden zusätzlich schadet es auch nicht das Arg -amfipassbeta mit aufzunehmen. Das Arg amfi=0x80 aus der Erfahrung heraus das manchmal der amfipass.kext nicht gleich beim ersten mal greift und macOS somit die vom Patcher eingebrachten Files abweist....

Wenn alles soweit parat ist kann sicherheitshalber der RootPatch mit der neuesten Version des Patchers nochmal ausgeführt werden und sofern WLAN dann tut was es soll kann das amfi=0x80 Arg wieder entfernt werden. In der folge kann nach einem Update einfach der Patch wieder angewendet werden und es sollte dann einfach laufen.

Native Lösungen für M.2 oder PCIe gibt es unter Sonoma nicht mehr hier muss im Falle von Broadcom IMMER mit dem Patcher gearbeitet werden im Falle von Intel halt mit den dazu gehörenden Kexten. Es gibt aber dennoch Lösungen die zumindest bis Sonoma ohne irgendwelche zusätzlichen Extensions (AirportBrcmFixup und BrcmPatchRAM3) auskommen hier wären zum Beispiel die Fenvi Karten zu nennen...

Diese Entwicklung ging dann tatsächlich an mir vorbei.

Natürlich ist die Reihenfolge dann wichtig, so wie Du es ja beschrieben hast, allerdings werden es jetzt immer mehr Kext's, die in Abhängigkeit zueinander stehen, was das Einimpfen zur Laufzeit beim Booten natürlich immer anfälliger macht.

Ausfälle beim Booten gab es auch damals schon mal hin und wieder, bei meiner DW1820 oder DW1550, so dass man nach Boot kein WLAN hatte und ein erneuter Neustart brachte alles zurück. Insbesondere auf älteren Rechnern war es hin und wieder mal so, die für manche Aktionen wohl einfach zu langsam waren, insbesondere nach Kaltstart.

Bootargs, wie -amfipassbeta oder -lilubetaall kann man jederzeit drin lassen, kann nicht schaden, auch wenn sie explizit nicht gebraucht werden. Den AMFIPass.kext gibt's ja auch schon in Version 1.4, wie ich gesehen habe.

Mit nativen Karten meinte ich natürlich die bislang nativen Karten, welche bis Ventura ohne Kext auskamen und unter Sonoma nur den Patch brauchen, ohne die Broadcom-Kext's.

Ich glaube damals bestand auch das Problem, das der OCLP PostInstaller die sogenannten nicht nativen Karten gar nicht erkannt hatte und den Patch für modern WLAN erst gar nicht mit ausgewählt hatte.

Bei den unsupported realMac's erkennt der Patcher ja, ob Grafik und/oder modern WLAN gepatcht werden muss, bei den Hacki's mit den sogenannten nativen Karten auch. Vielleicht muss man hier in dem Fall mal im Patcher genau schauen, ob der Patch überhaupt erkannt wird und auch gemacht wird, da es ansonsten ja auch nicht klappen kann, selbst mit den richtigen Einstellungen.

Naja die OCLP Leute sind an der Stelle dann doch mal ein wenig über ihren Schatten gesprungen und haben den Patcher so angepasst das er auch die nicht nativen Karten erkennt und den Patch anbietet wohl halt schon mit blick auf die eigentlich nicht gemochte/unterstützte Hackintosh Community In einem hast Du aber recht es wird halt durch das mehr an Abhängigkeiten nicht unbedingt einfacher...

Das mit dem OCLP kann ich so natürlich nicht mehr Testen, daher hatte ich diese Entwicklung auch nicht gesehen. Die Jungs vom OCLP sind da aber diesbezüglich schon in Ordnung, ganz sicher.

Ich hab zwar noch eine DW1550 in einem Uralt-Rechner auf Catalina, aber der ist noch mit DosDude gepatcht und da geht noch alles ohne Probleme.

Betreffs Verschlucken hatte ich ab 14.4 auf meinem T450s, welchen ich jetzt aber verkauft habe, auch sowas. Hierbei wurde insbesondere nach Kaltstart, auch mal nach Boot-Wechsel zum parallel-macOS-System der USBPort.kext verschluckt, welcher bis 14.3.1 eigentlich mehr als perfekt war.

Davon betroffen natürlich auch das BT, was ja am USB hängt. Mit jedem weiteren Neustart war wieder alles super.

Natürlich hat Apple mit 14.4 auch wieder am USB gebastelt, wie ich lesen musste und es wird sicher nicht einfacher.

Passierte auch nicht immer, manchmal war es sofort da.

Da wir ja nicht wie früher die Kext's direkt im System verändern, sondern alles nur noch bei jedem Boot ins System geimpft wird, werden solche Ausfälle sicher auch weiter schon mal vorkommen.

Über die evtl. nötigen Delay's zwischen den Prozessen können sicher nur die Jungs vom OC Auskunft geben, da bin ich raus. Ich kenne sowas nur aus meiner vergangenen Programmierzeit.