Anleitung für Intel WLAN mit AirportItlwm unter Sequoia und Tahoe

Man sollte noch zusätzlich erwähnen das der Heliport ohne jeglichen Eingriff ins System funktioniert.

Ortungsdienst geht mit dem Heliport nicht dafür vieles andere was der AirportItlwm nicht kann.

Das Update vom AirportItlwm auf Sequoia liegt in der Hand eines einzigen Entwickler. Finde ich schade da ich da leider nicht unterstützen kann.

Selbes gilt für Verbesserungen von diesem Kext. Potenzial wäre auch hier da, aber kein Entwickler.

bei mir läuft itlwm-HeliPort.app ohne Fake Device auf dem KBL-Desktop (Fenvi AX3000) und auf dem T460 AX210. Beides AX210 Chip. Etwas anders verhält es sich bei BT, dass löppt am KBL-Desktop auf 14.x undn 15.x bestens undn localsend dazu perfect. Am T460 nur mit 14.x, 15.x nix zu machen. Beim BT nützt ja auch ein Fake Divice nichts, dass ist ja reines USB Gerafffel.

EDIT: ......und genau um OCLP nicht mehr nutzen zu müssen bin ich auf Intel umgestiegen. Habe einfach keine Lust mehr 3-4 h FV2 erst zu ent- und später genau so lange wieder zu verschlüsseln.

Seit kurzem sind bei mir für BT die Einträg im Anhang nötig. Vielleicht helfen die auch bei dir wenn noch nicht versucht.

Die Einträge habe ich schon einige Zeit drin, allerdings noch nicht unter Delete. Das hole ich gleich mal nach. anonymous_writer

in dem Lorys89 Fork hatte ich gestern den Link zum Wifi-intel-KextsBuilder von @chris1111 gefunden. Vielleicht ist das hier auch von Interesse. Hat mir am T460 aber nicht weiter geholfen. Muss ich mich gedulden und hoffe auf einen gepatchten BlueToolFixup.kext.

EDIT: Die fehlnden Einträge im NVRAM (Delete bluetoothExternalDongleFailed + bluetoothInternalControllerInfo) und Bootarg (-btlfxallowanyaddr) haben am T460 unter 15.1. RC keine Verbesserung gebracht. Unter 14.7.1. sowie am KBL-Desktop für 15.1 RC und 14.7.1 keine Veränderung, da waren diese Einträge aber bislang auch nicht nötig gewesen.

Alle Kexte sind insoweit Nigthly und auf dem aktuell neuesten Stand.

Aus Interesse, wie sieht dieses Bild bei dir aus?

Quote from Arkturus

Die fehlnden Einträge im NVRAM (Delete bluetoothExternalDongleFailed + bluetoothInternalControllerInfo)

Warum sollten sie auch was bringen wenn du das in NVRAM/Delete hinzufügst?

Du musst das so vorstellen;
Alles was du unter NVRAM/Add dazu gehörigen Container hinzufügst wird beim Boot gelesen und angewendet.

Alles was du unter NVRAM/Delete dazu gehörigen Container hinzufügst wird beim neustarten herausgelöscht um vom ADD wieder frisch hinzugefügt zu werden.

Das erspart dir einfach einen NVRAM Reset und beugt zbspl. vor veraltete Nvram Einträgen die das Ergebnis fälschen könnten usw...

Gruss Coban

schrup21 mein Setup entspricht am KBL-Desktop als auch T460 genau dem, was du hier vorgestellt hast. Das habe ich aus dem Fork von Lorys89 schon recht früh übernommen. welcher hier auf Github in einem Thread von anonymous_writer verlinkt wurde. Die Einträge zum NVRAM/Delete habe ich von anonymous_writer übernommen, der mir freundlicherweise sein Setup zur Verfügung gestellt hatte. Es ist mir auch klar, dass die Delete Einträge auch alternativ durch NVRAM-Reset ersetzt werden. Aber es schadet jedenfalls nicht. Trotzdem Danke an cobanramo für die Erklärungen dazu.

Die Screen vom T460 stelle ich hier gleich nochmals ein.

Versuche mal mit BlueToolFixup.kext an erster Stelle.

Bild 2 zeigt das der Kext IntelBluetoothFirmware.kext nicht geladen wurde.

Ich habe schon alle Varianten in der Reihenfolge probiert. Ohne Erfolg. Die jetzige Reihenfolge habe ich jetzt beibehalten, weil diese dem Trobleshooting zur IntelBluetoothFirmware auf Github entspricht. Auf dem KBL-Desktop funktioniert BT unter macOS 15.x in jeder Variante und unter 14.x sowieso überall.
Im HackinTool wird die IntelBluethoothFirmware auch am T460 unter Extensions unter macOS 15.x als geladen angezeigt. Der Sytembericht sagt eben etwas anderes.

Die Einträge im NVRAM/Delete erübrigen ein NVRAM-Reset. Beim T460 ist das Bios relativ robust und das verträgt regelmäßiges NVRAM-Reset über die efi, am KBL-Desktop werden mir dabei jedesmal die die UEFI-Label ausradiert und ich muss die dann mühseelig per shell wieder setzen. Da machen die Einträge Sinn. Die tragen sonst natürlich nichts zur Funktionalität bei, wie cobanramo richtig bemerkte.

Wie ich schon schrieb funktioniert am T460 Intel-BT unter macOS 14.x, genauer jetzt aktuell 14.7.1 und auch unter Windows 11 schrup21 Es liegt deshalb nicht am USB-Mapping oder der IntelBluetootFirmware. Es wird eher am BluetoolFixup.kext liegen oder weiß der Teufel an was.

Ich werd verrückt. Habe mir das mehrmals angesehen und nicht entdeckt. Ich habe auch schon die EFI vom KBL-Desktop auf T460 umgebaut um zu sehen ob ich einen Fehler übersehen habe. Möglich das ich die Einträge zuerst im T460 drin hatte, der war zuerst auf Intel umgestellt und dann in den Desktop übertragen habe. Scheinbar ist es bei der Fenvi AX3000 ohne Bedeutung denn unter Sequoia geht auch BT.
bin mir fast sicher, dass ich zuletzt auch die plist von anonymous_writer reinkopiert habe, ohne Erfolg.

Ich mache nachher mal den Check.

EDIT: Das Problem ist reproduzierbar aber ich hab das nicht erkannt. Ich habe seinerzeit die EFI am T460 und auch jetzt nochmals beim rüberkopieren der BT-Settings.plist mit OCAT bearbeitet. Egal ob die erforderliche Anzahl der Nullen per Tatstatur oder Drag&Drop ausgefüllt werden, die Leerzeichen werden von OCAT mit Nullen gefüllt, was beim speichern auch zu sehen ist. Das ist mit nie aufgefallen, auch jetzt aktuell nicht. Da OCAT niemals zwei EFI zugleich bearbeiten kann, selbst wenn diese unterschiedlich benannt sind, öffne ich die Quell-plist im Plist-Editor und kopiere in die Ziel-plist im OCAT. Werde ich künftig nie wieder machen.

Danke für deine Ausdauer und Hilfsbereitschaft schrup21

jetzt sieht es so aus wie es sein soll:

Edit: ….. und ja, die EFI vom KBL-Desktop hat diesen Fehler nicht und die umgebaute EFI funktioniert sogar. Frag mich jetzt nicht wieso das beim Test nicht der Fall war. 🤷‍♂️

Ist die Anleitung noch aktuell? Ich habe das ganze exakt durchgeführt doch nach einen Neustart startet Sequoia nicht mehr und bleibt während dem Booten hängen.

Es hilft dann nur noch Opencore Legacy Patcher im recovery zurückzusetzen.

Hat jemand ne Ahnung woran das liegen kann?

da hat sich in den letzten Wochen nichts geändert yamaharacer , evtl. gibt es neuer Kext aber davon habe ich nichte bemerkt und mit den älteren gabs ja auchg keine Probleme. Hänger bei Booten sind nicht bekannt. Hast Du die EFI validiert? Wo genau bleibt es hängen? Sende mall eine Screenshot.

Anbei mal mein Bildschirm.

Ocvalidate sagt dass keine Fehler gefunden wurden.

Die Reihenfolge der kexts habe ich beachtet. Muss aber noch in Bezug auf die restlichen Kexts eine Reihenfolge bestehen?

Danke schon mal.

Mit dem Code kann ich nichts anfangen, vielleicht ein Experte hier im Forum ??

Ich empfehle dir erstmal ein Backup der EFI zu nutzen.