Beiträge von Reezy

Zitat von Leggalucci

Reezy Na da bin ich froh, dass ich mit diesem Problem nicht alleine bin und du es bereits erfolgreich lösen konntest. Was ich jedoch noch nicht ganz verstehe: Wenn ich HINTER der Fritzbox einen eigenen VPN betreibe z.B Wireshark oder wie du es bereits mit Strongswan betreibe - WIE ist dieser dann von außen erreichbar? Hier habe ich noch einen "knick", das verstehe ich nicht.

Der Server ist dann von außen per IPv6 erreichbar. Im Gegensatz zu IPv4 ist ja dein IPv6-Präfix, welches du von deinem Provider erhältst, von außen problemlos erreichbar. Dein Server hinter der Fritzbox erhält seine eigene global erreichbare IPv6-Adresse (so wie auch jedes andere Gerät in deinem Netz). Du musst dann nur für genau diese Adresse bzw. dieses Gerät ein paar Firewall-Anpassungen in der Fritzbox vornehmen, da die Fritzbox standardmäßig alle Verbindungen von außen filtert. Bei einem IKEv2/IPsec-VPN gehört dazu das Öffnen des Ports 500 sowie das Zulassen von ESP-Paketen. Das lässt sich beides recht einfach über das Fritzbox-Menü konfigurieren.

Da du Synology erwähnt hast: Für Synology gibt es eine prima Anleitung für die Einrichtung eines OpenVPN-Servers über IPv6. Schau mal hier.

Zitat von pebbly

Wenn du das ganze FritzBox Gedöns eingerichtet hast, dann müsstest du über deren DNS-Dienst (DynDNS Alternative) "immer" Zugriff per VPN haben.

Bezüglich des Verbindens, das machen Firmen ja auch. Also das geht alles.

Das stimmt so leider nicht. DynDNS ist eben auch nur ein DNS-Service und kein Relay. Es bietet dir damit lediglich einen Hostname zu deinen IP-Adressen. Das bringt dir aber nichts, wenn diese Adressen von außen nicht erreichbar sind, was hier durch Dual Stack Lite der Fall ist. Der VPN-Server der Fritzbox versteht aktuell nur IPv4 und von außen kannst du keine Verbindungen zu einem solchen Anschluss direkt über IPv4 aufbauen.

Das VPN der Fritzbox unterstützt leider immer noch kein IPv6. Ich warte da auch schon seit Jahren drauf. Mit der Fritzbox allein wirst du hier also nicht weiterkommen, wenn du keine öffentliche IPv4-Adresse hast.

Ich habe nun schon seit einigen Jahren stattdessen einen separaten VPN-Server hinter der Fritzbox. Das ganze läuft über Strongswan mit IKEv2/IPsec und unterstützt problemlos IPv4 getunnelt in IPv6 und umgekehrt. Natürlich kann man damit auch ganze Netze miteinander verbinden. Für einen solchen Server könnte ein Raspberry Pi schon ausreichen.

Es gibt noch weitere Alternativen wie WireGuard, was gerade sehr angesagt ist.

Es gibt noch die beiden Apps SoundSource und Sound Control. Damit kann man dann die Lautstärke auch von digitalen Ausgängen steuern.

Du kannst einen anderen Browser auch ohne Safari herunterladen. Öffne dazu die Terminal-App und gib folgenden Befehl ein:

Die Datei firefox.dmg liegt dann anschließend in deinem Downloads-Ordner und kann wie gewohnt durch Doppelklicken geöffnet werden.

Dass die Seite wegen eines Problems neu geladen werden muss, deutet für mich eher auf einen Crash eines Safari-Prozesses und nicht auf ein Netzwerkproblem. Wie verhalten sich denn andere Browser?

Hatte das gleiche Vorhaben. Auch bei mir war es ein interner Connector, an den ich dieses Slotbloch angeschlossen habe, und es war zunächst nichts zu hören. Habe dann ebenfalls versucht, die Kext manuell nach diesem PDF zu patchen, aber es half nicht.

Irgendwo in einem Forum bin ich dann auf den Tipp mit Layout 99 gestoßen. Sobald ich dieses Layout in meiner config.plist eingestellt hatte, funktionierte der Ton über den optischen Ausgang, und zwar mit der ungepatchten AppleALC.kext. Also vielleicht probierst du erst einmal mal ein paar andere Layout IDs bei dir.

Ein Hinweis noch für später: Die Lautstärke lässt sich bei digitalen Ausgängen nicht über macOS regeln. Hier helfen nur die Apps SoundSource oder Sound Control.

Hallo Leute!

EDIT: Lösung weiter unten.

Ich bin vor wenigen Wochen von Clover auf OpenCore umgestiegen. Dabei bin ich Schritt für Schritt nach den Dortania Guides vorgegangen und es hatte auf Anhieb alles funktioniert. Mein Rechner läuft seitdem absolut rund und auch auf Big Sur konnte ich in der Zwischenzeit bereits updaten.

Leider gibt es jedoch eine Ausnahme, ein Problem, das seit dem Wechsel auf OpenCore auftritt: Jedes Mal, wenn ich den Rechner hochfahre oder aus dem Schlaf wecke, sind Datum und Uhrzeit falsch. Nach dem Booten liegt das Datum gerne mal um Jahre in der Zukunft und während des Schlafs bleibt die Uhr scheinbar einfach stehen. Meist dauert es einige Sekunden, bis macOS mit einem NTP-Server synchronisiert hat und die Anzeige wieder korrekt ist.

Leider führt dies jedoch trotzdem während dieser paar Sekunden gerne mal zu negativen Begleiterscheinungen. Zum Beispiel werde ich gerne mal mit allerhand Fehlermeldungen konfrontiert, da sich macOS mal wieder in der Zukunft glaubt und daher alle erdenklichen SSL-Zertifikate vermeintlich abgelaufen sind. Des Weiteren hatte ich einen hartnäckigen Fehler, bei dem macOS eine Konfigdatei mit einem solchen Datum versehen hat und damit den Dienst fontd dazu brachte, dauerhaft auf 100 % CPU zu laufen, bis ich die Ursache gefunden hatte.

Also scheinbar funktioniert die Kommunikation mit der Real Time Clock des Rechners nicht richtig. Die SSDT-RTC0.aml ist gemäß Guide bei mir vorhanden und auch diese Schritte habe ich bereits ausprobiert, an der Knopfzelle kann es nicht liegen. Im BIOS und in Windows werden Datum und Uhrzeit auch korrekt angezeigt.

Vielleicht hat jemand von euch eine Idee. Dankeschön!

Mein Setup:

Gigabyte H370M DS3H

Intel Core i5 8400

Radeon RX 570

macOS 11.0.1

OpenCore 0.6.3

iMacPro1,1

----- EDIT -----

Wie es aussieht, konnte ich das Problem selbst lösen. Hier mein Lösungsweg:

Zunächst habe ich mir noch einmal genau die Dortania Anleitung zu SSDT-RTC0.aml durchgelesen, da ich bei dieser SSDT den Fehler vermutet habe. Und wie sich herausstellt, habe ich diese ursprünglich wohl missverstanden. Da mein System keine AWAC hat (Suche nach ACPI000E liefert keine Ergebnisse), hätte ich nach dem Satz „If nothing shows up, you don't need to do anything for AWAC or RTC“ einfach aufhören können. Tatsächlich habe ich jedoch die restliche Anleitung noch weiter verfolgt und mir damit eine SSDT-RTC0.aml erstellt, die in meinem Fall nicht nötig gewesen wäre.

Also habe ich diese SSDT nun gelöscht und siehe da: macOS übernimmt nach dem Booten wieder korrekt die Zeit aus der CMOS Clock.

Dennoch blieb die Zeit während des Sleeps nach wie vor stehen. Im BIOS fiel mir jetzt erst auf, dass auch dort die Sekunden einfach stehengeblieben sind. Die CMOS Clock tickte also nicht richtig – im wahrsten Sinne des Wortes. Ich nehme an, dass macOS durch die fälschliche SSDT irgendwas im CMOS durcheinandergebracht hat und die Uhr deswegen nicht mehr weiterlief.

Die Lösung für dieses Problem war ein kompletter Reset des CMOS. Habe dazu einfach kurz das Netzteil ausgeschaltet und die Knopfzelle herausgenommen. Die BIOS-Einstellungen habe ich vorher auf einen USB-Stick gesichert. Nach dem Reset tickte die Uhr wieder ganz normal. Auch im macOS Sleep bleibt die Zeit nicht mehr stehen.

Somit ist das Problem komplett gelöst. ☺️