Entsperren mit der Watch seit Catalina nicht mehr möglich

    Moin,


    vorweg. Mit High Sierra hatte ich keine Probleme, die Watch wurde mit meiner Airport Karte wunderbar entsperrt.


    Diese Karte nutze ich. https://www.amazon.de/gp/produ…tle_o00_s00?ie=UTF8&psc=1


    Sie läuft ohne Kexte oder Fixe, einfach OOB.


    Continuity funktioniert, Handoff, App und Einkäufe entsperren und wenn das Gerät in den Ruhezustand geht und ich eine Taste drücke entsperrt er auch super.



    Beim Start ist auch der passende Dialog da.



    Nach Sleep allerdings versucht er nicht einmal zu verbinden (kein BT Timeout), sondern geht gleich in die PW Eingabe.


    Das BT Modul hat dauerhaft Strom, daher hat es ja bis HS gut funktioniert.


    Alle Geräte wurden aus der Cloud entfernt, die Watch neu gekoppelt, verschiedene darkwakes ausprobiert, Config entsprechend der HS angepasst. Alles nix.


    Einer eine Idee?

    Hast du deine USB Ports korrekt gemappt?

    Das BT wird ja intern via USB angebunden. Wenn das nicht 100% passt, kann das dein Problem verursachen

    Meine Systeme


    Support ausschließlich im Forum und NICHT per PN!

    Danke Jono


    Ja, ist richtig als intern gemappt. Sonst würde Sleep ja auch nicht laufen. Sonst läuft die Karte OOB.


    Ansonsten hilft es in solchen Fällen oft alle beteiligten Geräte einmal von der iCloud ab und wieder anzumelden ;)

    Haswell, Notebook

    Hallo griven


    danke hatte ich doch schon. 😉


    Zitat: Alle Geräte wurden aus der Cloud entfernt, die Watch neu gekoppelt, verschiedene darkwakes ausprobiert, Config entsprechend der HS angepasst. Alles nix


    Wie gesagt, es funktioniert ja alles, ausser nach Sleep.


    Habe hier aber noch einen interessanten Thread zu USB Patching gefunden.


    Wenn morgen meine Inateck kommt gehe ich da noch mal ran und berichte danach.


    Ich habe einen Verdacht.


    UPDATE:


    Leider habe ich mit tatsächlich mit dem Big Sur Update, das ich abgebrochen habe meine APFS Dateistruktur zerschossen und musste das System aus TM wiederherstellen. Danach kann ich mit Watch entsperren nicht mehr aktivieren. Das löse ich jetzt erst einmal.


    So...zum Thema von gestern und dem Beitrag.


    Anhand des folgenden Links konnte ich nach Einbau der Inateck Karte noch einmal das wesentlich nachvollziehen. Habe unter 15.1 eine neue USBPort.kext erstellt, auf 1.1 umgeschrieben, die ssdt-ec-usbx.aml ins ACPI/patched einfügt und dann im IOReg geprüft.


    ApplePowerBusPowerController wird geladen.



    Gerät EC taucht nicht auf, habe aber in der DSDT nachgeschaut und dort ist es eingebaut.



    Sieht so aus, als wenn kuckkuck und al6042 hier schon alles eingebaut haben. Daher lädt wohl auch der PowerController.


    EH01, EH02 und XHC sind da auch schon drin. Ob die Werte korrekt sind, dazu bin ich stand heute zu wenig im Thema drin.





    Aus meiner Sicht sollte also am USB nichts mehr klemmen. Sleep funktioniert auch tadellos.


    Ich melde mich noch mal.

    2 Mal editiert, zuletzt von G.com ()

    G.com In deinen USBPorts.kext werden die "IOProviderMergeProperties" ausreichend definiert.

    In deiner ssdt-ec-usbx.aml, die du ja auch im Einsatz hast, werden diese jeweiligen parameter aber wiederholt definiert, das verursacht das der registry explorer den erforderlichen EC "dummy" Eintrag nicht anzeigt.

    Abhilfe:

    Verwende eher nur eine SSDT-EC.aml, natürlich zugestrickt auf dein System, die diese

    "IOProviderMergeProperties" nicht "wiederholt" deinen System anbietet, wenn deine USB port mappings durch einen USBPorts.kext dein USB bedarf deines System steuert.

    Eine SSDT-EC.aml Datei die in meinen Comet Lake hack im Einsatz ist habe ich also Vorbild angeheftet. Schlage vor du vergleichst meine Datei mal mit deiner ssdt-ec-usbx.aml sowie auch die

    "IOProviderMergeProperties" Eintraege in der info.plist Datei deines USBPorts.kext's, dann wird dir, und einigen Anderen wahrscheinlich ein Licht aufgehen. Meines Erachtens ist es eine "Nebenerscheinung", das den meisten die einen USBPorts.kext im Einsatz haben beobachten werden, aber das überlass ich natürlich diejenigen denen das vermutlich etwa interessieren wird, "the rest should obviously just plod along the way they have always done and been happy with."


    Gruesse Henties

    Dateien

    • SSDT-EC.aml

      (125 Byte, 122 Mal heruntergeladen, zuletzt: )

    henties

    Danke! Habe ich gemacht und eine SSDT-EC erstellt. Allerdings habe ich schnell SSDTtime benutzt.


    ABER. Jetzt habe ich zwei Fake EC Geräte. Einmal aus der DSDT von al6042 und dann noch einmal über die SSDT.


    DSDT: EC00000



    SSDT: ACID0001



    Die DSDT kann ich nicht editieren, da Compiler Fehler entstehen.


    Ich stoße gerade erst in diese Tiefe und bin da noch nicht so firm.


    Kann das so bleiben oder hackt das?

    Any idea? BTW - ich lerne gerne. [meld]


    UPDATE: Also, alle USB Ports laufen jetzt. Entsperren mit der Watch läuft. Continuity, Handoff läuft. Abwarten, ob das Entsperren jetzt funktioniert. Zwischenzeitlich hat es das.

    Einmal editiert, zuletzt von G.com ()

    G.com Kann dir leider nicht weiter helfen den ich steuere alle meine Bios Änderungen nur über SSDT.aml "intercepts". Seit OC sind DSTD "considerations in my hacking endeavours" überflüssig, und kenne mich deshalb nicht diesbezüglich in der OC Umgebung aus.


    Gruesse Henties

    Oha - da habe ich zwei Tage getüftelt, mein System zerschossen mit versehentlichem Starten und Abbrechen der Big Sur Installation aus OSX heraus... :oops:


    Und nun das, aus reiner Verzweiflung, habe ich einfach Cataline neu geladen und "neu" installiert, also bestehende Installation erneuert. Entsperren funktioniert zuverlässig! Bei jedem Sleep.


    Dann funktioniert das auch [floet]

    Einmal editiert, zuletzt von G.com ()

    Also, nach logout in Cloud hakte es nach erneutem Login ein wenig. Jetzt rennt es aber 100%. Vielleicht braucht es manches Mal einfach Zeit. Meinem Hacki fehlt damit nix.