Eine Tastatur, zwei Rechner — und ein Laptop, der in der Schublade bleibt.

Auf dem Schreibtisch steht ein MacBook Air. In der Schublade darunter liegt ein Windows-Laptop — zugeklappt, an einem externen Monitor, der Zweitrechner für die Dinge, die es nun mal nur für Windows gibt. Für jede Kleinigkeit brauchte es bisher eine zweite Tastatur, eine zweite Maus, und einmal Schublade auf.

Das Ziel war in drei Stufen formuliert: Mac-Tastatur und -Trackpad steuern den Windows-Laptop mit. Die gewohnten Mac-Kürzel funktionieren dort ebenfalls. Und der Laptop lässt sich wecken und bedienen, ohne die Schublade zu öffnen — inklusive Anmeldebildschirm.

Alle drei Stufen laufen. Eine vierte nicht, und die ist der interessanteste Teil, weil sie sich prinzipiell nicht lösen lässt. Was jetzt kommt, ist der vollständige Werkstattbericht: mit den Befehlen, den Fehlermeldungen und vor allem den Sackgassen.

KI-Fassung Original

Eine Randnotiz zum Bild, die hier ganz gut hinpasst: Die aufgeräumte Fassung stammt von ChatGPT. Sie hat den Raum aber nicht nur aufgeräumt, sie hat ihn teilweise neu erfunden. Das Bücherregal, die Tischlampe und das gerahmte Bild an der Wand gibt es so nicht — im Original stehen dort Modellautos und ein Rollwagen mit Kram, auf dem Tisch liegen zusätzlich ein Controller und eine Fernbedienung. Und auf dem Mikrofon steht statt RODE ein verdrehtes „ЯODЯ“. Als Stimmungsbild funktioniert das. Als Dokumentation eines Aufbaus nicht — was ganz gut zum Rest dieses Beitrags passt: Etwas, das plausibel aussieht, ist noch kein Beweis.

Was Deskflow macht — und was nicht

Deskflow ist quelloffene Software, um Tastatur und Maus über das Netzwerk zwischen mehreren Rechnern zu teilen. Es ist der Community-Nachfolger von Synergy 1 und tritt die Nachfolge des eingeschlafenen Barrier-Projekts an.

Der wichtigste Satz zum Verständnis des ganzen Aufbaus: Es ist kein Remote-Desktop. Es wird kein Bildschirminhalt übertragen. Jeder Rechner zeigt weiter sein eigenes Bild auf seinem eigenen Monitor. Übertragen werden ausschließlich Eingabeereignisse und die Zwischenablage. Der Mauszeiger wandert über eine gedachte Bildschirmkante auf den anderen Rechner, und ab da bekommt dieser die Tastatureingaben.

Ein Rechner ist Server — der mit der physischen Tastatur und Maus —, alle anderen sind Clients. Gesprochen wird auf Port 24800.

Version auf beiden Seiten: 1.26.0. Das ist keine Formalie — bei unterschiedlichen Versionen sind Protokollfehler und sonderbares Verhalten sehr wahrscheinlich.

Installation

Mac

brew tap deskflow/tap
brew trust deskflow/tap
brew install --cask deskflow

Stolperstein 1: der mittlere Befehl. Homebrew verlangt seit einiger Zeit, dass fremde Taps explizit als vertrauenswürdig markiert werden. Lässt man ihn weg, bricht die Installation ab:

Error: Refusing to load cask deskflow/tap/deskflow from untrusted tap deskflow/tap.

Homebrew empfiehlt dabei, nur den konkreten Cask zu vertrauen statt des gesamten Taps — brew trust --cask deskflow/tap/deskflow. Das ist der feinere Weg, weil das Vertrauen dann nicht automatisch für alle künftigen Inhalte dieses Taps gilt. Nebenbei eine schöne Beobachtung: Homebrew hat hier in den letzten Versionen sichtbar an der Lieferketten-Sicherheit gearbeitet.

Es gibt zwei Casks: deskflow für die stabilen Releases und deskflow-dev für die Continuous Builds.

Windows

winget install --id Deskflow.Deskflow -e

Die drei Berechtigungen auf dem Mac

Ohne diese drei startet Deskflow zwar, tut aber nichts oder nur die Hälfte. Und die Fehlersuche ist zäh, weil es keine klare Fehlermeldung dazu gibt:

• Bedienungshilfen — ohne sie kann Deskflow keine Eingaben erzeugen. Falls der App-Eintrag allein nicht reicht: im Finder per Rechtsklick auf Deskflow.app → „Paketinhalt zeigen“, und die Binaries aus Contents/MacOS einzeln in die Liste ziehen.
• Eingabeüberwachung — für das Abgreifen von Tastatur und Trackpad.
• Lokales Netzwerk — seit macOS 15 eine eigene Kategorie und ein häufiger Stolperstein. Ohne sie darf die App schlicht keine LAN-Verbindungen aufbauen, auch bei ausgeschalteter Firewall.

Dazu kommt beim ersten Start die Firewall-Abfrage für eingehende Verbindungen. Und falls macOS die App als „beschädigt“ meldet, was bei unsignierten Builds vorkommt:

xattr -d com.apple.quarantine /Applications/Deskflow.app

Die Alias-Falle — und wer die Konfigurationsdatei wirklich schreibt

Am Mac wird im Server-Modus das Bildschirm-Layout konfiguriert: ein neuer Screen wird per Drag links neben den eigenen gesetzt und exakt auf den Windows-Hostnamen umbenannt. Den liefert auf Windows ein hostname. Am Client wird derselbe Screen-Name eingetragen, dazu die Server-IP.

In der Annahme, Groß- und Kleinschreibung könnte Ärger machen, wurden für den Screen WINLAPTOP vorsichtshalber die Aliase WINLAPTOP und winlaptop hinterlegt. Das Ergebnis:

ERROR: cannot read configuration ".../deskflow-server.conf":
       read error: line 20: alias "winlaptop" is already used
FATAL: deskflow-core: failed to load config
WARNING: desktop process exited with code: 4

Der Grund: Deskflow vergleicht Screen-Namen ohnehin ohne Rücksicht auf Groß- und Kleinschreibung. Ein Alias, der sich nur in der Schreibweise vom Screen-Namen unterscheidet, ist damit eine Dublette — und der Core startet gar nicht erst. Die vorsorgliche Maßnahme war also nicht überflüssig, sie war die Ursache.

Der lehrreichere Teil kam danach. Der Fehler ließ sich nicht durch Bearbeiten von ~/Library/Deskflow/deskflow-server.conf beheben. Die grafische Oberfläche hält ihre eigene Kopie des Layouts in Deskflow.conf und schreibt die Server-Konfiguration bei jedem Start neu. Alle Datei-Edits waren wirkungslos; der Alias musste im Dialog „Configure Server“ raus.

Der eine Befehl, der Zeit spart

Bevor man reflexhaft die Firewall verdächtigt, sagt dieser Befehl auf dem Mac in einer Sekunde, ob der Server überhaupt läuft:

lsof -nP -iTCP:24800 -sTCP:LISTEN

Keine Ausgabe heißt: kein Server. Also kein Netzwerkproblem, sondern ein Startproblem — und die Ursache steht im Log, nicht in den Firewall-Einstellungen.

TLS: alles oder nichts

Mit reparierter Konfiguration kam beim nächsten Verbindungsversuch das hier:

ERROR: failed to accept secure socket
WARNING: client connection may not be secure

Ursache: Die TLS-Einstellungen stimmten auf beiden Seiten nicht überein. Das ist eine Alles-oder-nichts-Entscheidung — entweder beide Seiten mit TLS und gleicher Schlüssellänge, oder beide ohne. Für den sauberen Neuaufbau räumt man die alten Zertifikate weg (Mac: ~/Library/Deskflow/tls, Windows: %LOCALAPPDATA%\Deskflow\tls) und lässt beim nächsten Start neue erzeugen. Beim ersten Verbinden zeigen dann beide Seiten einen Fingerprint zum Vergleichen und Bestätigen.

In diesem Aufbau blieb TLS aus. Für ein privates Heimnetz vertretbar — aber ehrlich eingeordnet: Ohne TLS wandern Tastatureingaben unverschlüsselt durch das lokale Netz, potenziell also auch Passwörter. In einem WG-Netz, einem Büro oder einem Gäste-WLAN wäre das keine gute Idee.

Mac-Kürzel auf Windows

Die eigentliche Komfortfrage: Cmd+C und Cmd+V sollen auch drüben funktionieren, weil die Finger nun mal an der Mac-Tastatur liegen. Deskflow kann Modifier-Tasten pro Screen umbiegen — im Server-Dialog beim Screen WINLAPTOP, Reiter „Modifier keys“:

Warum sowohl Super als auch Meta: Die Command-Taste wird je nach Konstellation als das eine oder das andere gemeldet. Beide zu belegen erspart das Ausprobieren. In der erzeugten Konfiguration sieht das dann so aus:

WINLAPTOP:
    super = ctrl
    meta = ctrl
    ctrl = super

Die Zuordnung gilt nur, solange der Zeiger auf dem Client steht. Auf dem Mac bleibt alles wie gewohnt. Was sich dadurch im Alltag ändert:

• Cmd+C, Cmd+V, Cmd+A, Cmd+S funktionieren wie erwartet.
• Option bleibt Alt — Option+Tab ist also das Alt-Tab.
• Cmd+Tab wird zu Strg+Tab. Im Browser also Tab-Wechsel statt Programmwechsel. Daran muss man sich gewöhnen.
• Die Mac-Control-Taste öffnet jetzt das Startmenü.

Die Zwischenablage wird ohnehin synchronisiert, Kopieren über die Gerätegrenze hinweg funktioniert also.

Der Windows-Dienst: warum er der Dreh- und Angelpunkt ist

Das Symptom war merkwürdig: Deskflow funktionierte — aber in einem PowerShell-Fenster, das als Administrator lief, kam kein einziger Tastenanschlag an. Mit der direkt angeschlossenen USB-Tastatur ging es sofort.

Die Ursache: UIPI

Windows kennt die User Interface Privilege Isolation. Ein Prozess darf keine Eingaben an ein Fenster schicken, das mit höheren Rechten läuft als er selbst. Sonst könnte jedes beliebige Programm dem Administrator-Fenster Befehle unterschieben. Die Isolation ist also kein Schikane-Feature, sondern eine tragende Säule des Rechtemodells.

Deskflow lief zu diesem Zeitpunkt als normaler Benutzerprozess. Damit war es für erhöhte Fenster, UAC-Dialoge und den Anmeldebildschirm schlicht unsichtbar.

Die Lösung

Deskflow bringt für genau diesen Zweck einen Hintergrunddienst mit, der als SYSTEM läuft. In den Einstellungen unter „Advanced“:

• Use background service (daemon) aktivieren
• Always run as system (work at login screen and UAC) — wird erst anklickbar, wenn die erste Option gesetzt ist

Dieses Optionspaar ist in Version 1.26 der Nachfolger des früheren „Elevate-Modus“ mit den Stufen auto/always/never, den ältere Anleitungen im Netz noch beschreiben. Die alte Voreinstellung „auto“ war genau deshalb ein verbreitetes Ärgernis: Sie holte sich ein nicht-erhöhtes Token und scheiterte still an Sperrbildschirm und UAC.

Damit der Dienst auch nach einem Absturz zurückkommt:

sc.exe config Deskflow start= auto
sc.exe failure Deskflow reset= 60 actions= restart/5000/restart/5000/restart/5000

Die zweite Zeile sorgt dafür, dass Windows den Dienst nach einem Absturz drei Mal im Abstand von fünf Sekunden neu startet, statt ihn liegen zu lassen.

Zwei Nebenwirkungen, die wie Fehler aussehen

Deskflow läuft weiter, wenn man das Fenster schließt. Das ist korrekt: Das Fenster ist nur die Bedienoberfläche, die Verbindung hält der Dienst. Beenden geht über „Stop“ in der App oder Stop-Service Deskflow.

Die Zwischenablage zickt gelegentlich zwischen erhöhten und normalen Programmen. Dieselbe Isolation, die das Tastaturproblem löst, macht hier den Austausch komplizierter.

Fehler 1067

Beim ersten Versuch startete der Dienst gar nicht:

STATE            : 1  STOPPED
WIN32_EXIT_CODE  : 1067  (0x42b)

1067 heißt „Prozess unerwartet beendet“ — der Dienst existiert, stirbt aber beim Start. Häufigste Ursache ist ein Versionsversatz zwischen Dienst und App nach einem Update. Die Reparatur ist eine Neuinstallation des Daemons:

& "C:\Program Files\Deskflow\deskflow-daemon.exe" --uninstall
& "C:\Program Files\Deskflow\deskflow-daemon.exe" --install
Start-Service Deskflow

Das Daemon-Log liegt unter C:\ProgramData\Deskflow\deskflow-daemon.log.

Wake-on-LAN: den Laptop aus der Schublade wecken

Die naheliegende Idee, die nicht funktioniert

Ein smarter Zwischenstecker: Strom weg, Strom an, Laptop startet. Das funktioniert bei Desktop-Rechnern mit der passenden BIOS-Einstellung („Power On by AC“) — bei einem Laptop aber nicht. Der hat einen Akku. Für ihn bedeutet ein abgeschalteter Stecker nur „läuft jetzt auf Batterie“.

Was der Zwischenstecker sinnvoll kann: das Dauerladen bei 100 % unterbrechen. Das schont den Akku, löst aber ein anderes Problem.

Bestandsaufnahme

powercfg /a
Get-NetAdapter -Physical | Format-Table Name,InterfaceDescription,Status

Der erste Befehl listet die verfügbaren Energiesparzustände, der zweite die Netzwerkkarten. Das Ergebnis und was es bedeutet:

• S3 verfügbar, S0 Modern Standby nicht. Also klassischer Standby, aus dem Netzwerkkarten zuverlässig aufwecken können. Bei Modern-Standby-Geräten ist die Lage deutlich komplizierter.
• WLAN: Intel Wireless-AC 9560. Intel-WLAN-Karten unterstützen unter Windows kein Wake on Wireless LAN. Das ist keine Fehlkonfiguration, sondern schlicht nicht implementiert — ein wichtiger Punkt, weil viele Anleitungen Wake-on-LAN beschreiben, als ginge es über WLAN einfach mit.
• Ethernet: Realtek PCIe GbE, „Disconnected“. Der Laptop hatte also die ganze Zeit einen brauchbaren Port, an dem nur kein Kabel steckte. Realtek-Karten verarbeiten Magic Packets sowohl aus S3 als auch aus S5, also im ausgeschalteten Zustand.

Damit war die Entscheidung gefallen: LAN-Kabel in die Schublade.

Einrichtung auf Windows

Get-NetAdapter -Name Ethernet | Select-Object Name,MacAddress,Status
powercfg /devicequery wake_armed
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power' -Name HiberbootEnabled -Value 0

Der erste Befehl liefert die MAC-Adresse, die man gleich braucht. Der zweite listet alle Geräte, die den Rechner wecken dürfen — der Realtek-Adapter muss dort auftauchen.

Der dritte Befehl ist der entscheidende: Er schaltet den Schnellstart ab. Das ist die häufigste Ursache dafür, dass Wake-on-LAN „manchmal“ nicht geht. Mit aktiviertem Schnellstart ist „Herunterfahren“ in Wahrheit ein Hybrid-Zustand, in dem die Netzwerkkarte stromlos ist. Erst ohne ihn landet der Rechner in echtem S5, aus dem die Karte aufwachen kann. Nach größeren Windows-Updates kann der Wert zurückgesetzt werden — ein Punkt für die Checkliste.

Falls es dann immer noch nicht klappt, sind die Treiber-Einstellungen des Adapters dran (Geräte-Manager → Energieverwaltung sowie „Erweitert“):

• Wake on Magic Packet → aktiviert
• Shutdown Wake-On-Lan → der Schalter speziell für S5
• WOL & Shutdown Link Speed → 10 Mbps First oder 100 Mbps First, nicht „Not Speed Down“. Die Karte muss im ausgeschalteten Zustand mit reduzierter Geschwindigkeit am Netz bleiben.

Und schließlich das BIOS. Der Eintrag heißt je nach Hersteller Wake on LAN, Power On by PCIe oder Resume by LAN.

Einrichtung auf dem Mac

brew install wakeonlan
echo 'alias wakelaptop="wakeonlan -i 192.168.0.255 AA:BB:CC:DD:EE:FF"' >> ~/.zshrc
source ~/.zshrc

Wichtig: Die Adresse hinter -i ist die Broadcast-Adresse des Subnetzes, nicht die IP des Laptops. Das ist der Kern des Verfahrens — ein schlafender Rechner hat keine aktive IP-Adresse mehr. Deshalb geht das Magic Packet an alle, und die Netzwerkkarte fischt es anhand ihrer MAC-Adresse heraus.

Danach weckt wakelaptop den Laptop sowohl aus dem Standby als auch aus dem heruntergefahrenen Zustand. Der Deskflow-Dienst verbindet sich von allein wieder zum Mac.

Damit der Rechner nach einem unbeaufsichtigten Aufwachen nicht nach zwei Minuten wieder einschläft — und für den sparsamen Betrieb trotzdem irgendwann:

powercfg /setacvalueindex SCHEME_CURRENT SUB_SLEEP 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 0
powercfg /setactive SCHEME_CURRENT
powercfg /change standby-timeout-ac 30

Zur Größenordnung: Ein zugeklappter, wacher Laptop zieht grob 5–10 Watt, über ein Jahr also etwa 20–35 Euro Strom. Im Standby sind es unter einem Watt.

Das Kapitel, das im Sand verlief: Scrollen

Der Mauszeiger ließ sich schnell in den Griff bekommen. Das Scrollen mit dem Mac-Trackpad fühlte sich auf Windows dagegen dauerhaft falsch an: zu schnell, sprunghaft, und nach dem Loslassen lief es noch eine ganze Weile weiter.

Der einfache Teil

Der Zeiger beschleunigte doppelt — macOS legt seine Kurve auf die Bewegung, Windows legt seine eigene obendrauf. Lösung auf der Windows-Seite:

Set-ItemProperty 'HKCU:\Control Panel\Mouse' -Name MouseSpeed -Value "0"
Set-ItemProperty 'HKCU:\Control Panel\Mouse' -Name MouseThreshold1 -Value "0"
Set-ItemProperty 'HKCU:\Control Panel\Mouse' -Name MouseThreshold2 -Value "0"

Oder über die Oberfläche: Win+R, main.cpl, Reiter Zeigeroptionen, Haken bei „Zeigerbeschleunigung verbessern“ entfernen, Geschwindigkeit auf die mittlere Raste. Danach klebt der Zeiger am Finger.

Der Teil, der eskalierte

Für das Scrollen entstanden nacheinander vier Versionen eines AutoHotkey-Skripts:

1. Zeitsperre — höchstens ein Wheel-Event alle 30 ms. Ergebnis: hakelig, weil Ereignisse einfach verworfen wurden. Dazu AutoHotkeys eigene Flut-Warnung, weil das Trackpad über 70 Ereignisse pro Sekunde erzeugte. Nebenbei der Beweis, dass nicht die Schrittweite das Problem war, sondern die schiere Menge.
2. Untersetzung — jedes n-te Ereignis durchlassen, das erste einer Geste sofort. Flüssiger, aber insgesamt zu langsam, weil auch gemächliches Scrollen gebremst wurde.
3. Adaptiv — nur untersetzen, wenn die Ereignisse schneller als 25 ms aufeinander folgen. Deutlich besser.
4. Momentum-Erkennung — nach einer schnellen Phase gelten monoton größer werdende Abstände als Auslauf und werden verworfen.

Danach wurde alles wieder entfernt. Die Lösung wurde nicht besser, sie wurde nur komplizierter, und das Grundgefühl blieb falsch.

Warum es prinzipiell nicht geht

macOS scrollt pixelgenau. Das Trackpad liefert viele kleine Deltas pro Sekunde, und jedes trägt eine Phasen-Markierung: Liegt der Finger noch auf, oder ist das schon Trägheit nach dem Loslassen? Die Anwendung verschiebt den Inhalt um exakt diese Pixel. Daher das flüssige, physikalische Gefühl.

Die klassische Maus-Schnittstelle von Windows kennt nur Rasten. Ein Ereignis bedeutet „drei Zeilen weiter“, fertig. Deskflow muss die feinen Pixel-Deltas also in ganze Rastschritte umrechnen. Dabei passieren zwei Dinge gleichzeitig:

• Der Momentum-Schweif, auf dem Mac aus hunderten Mini-Bewegungen bestehend, kommt drüben als Salve von Rast-Klicks an. Und weil die Trägheitskurve am Anfang am schnellsten ist, wirkt sie wie ein Sturzflug.
• Die Phasen-Markierung geht komplett verloren. Windows kann grundsätzlich nicht wissen, ob der Finger noch auf dem Trackpad liegt. Jede Erkennung auf der Empfängerseite bleibt deshalb Rateerei.

Sauber lösen ließe sich das nur, wenn Deskflow sich als echtes Precision Touchpad ausgäbe. Pixelgenaue Pan-Ereignisse nimmt Windows aber ausschließlich von einem signierten HID-Treiber im Kernelmodus an. Ein KVM-Programm müsste also einen virtuellen Gerätetreiber mitliefern — deshalb kann es keines: weder Deskflow noch Synergy noch Barrier.

Was praktisch bleibt: WheelScrollLines auf 2 oder 3 stellen, im Browser „Smooth Scrolling“ abschalten — oder für längere Windows-Sitzungen schlicht eine echte Maus mit Scrollrad benutzen, deren Rasten ohne Beschleunigungskurve ankommen.

Der Fehler zum Schluss: ein loses Kabel

Nach einigen Tagen reagierte der Laptop nicht mehr auf wakelaptop. Die Fehlersuche lief in drei Schritten:

1. Mac-Seite prüfen. ipconfig getifaddr en0 bestätigte dasselbe Subnetz, alias wakelaptop die richtige Broadcast-Adresse und MAC, und der Befehl meldete das Paket als verschickt. Die Mac-Seite war damit ausgeschlossen.
2. ARP-Tabelle. Blieb leer. Wichtig zu wissen: Das beweist nichts. Eine schlafende Karte im WoL-Modus antwortet nicht auf ARP-Anfragen, sie horcht nur auf das Magic Packet.
3. Router-Oberfläche. Und dort stand im Status-Block unter Ethernet schlicht LAN1: Unplugged.

Das Kabel saß nicht richtig. Ohne Link erreicht kein Magic Packet den Laptop, und sämtliche BIOS- und Registry-Einstellungen sind irrelevant.

Die Lehre daraus: Bei Wake-on-LAN ist die Statusseite des Routers das erste Diagnosewerkzeug, nicht das letzte. Sie beantwortet in zwei Sekunden die Frage, ob überhaupt eine physische Verbindung besteht — bevor man anfängt, in Energieoptionen und Treiber-Einstellungen zu suchen.

Mit einer wichtigen Einschränkung: Das gilt nur, wenn der Rechner direkt am Router hängt. Läuft die Strecke über Powerline-Adapter, zeigt der Router nur den Link zum Adapter an seinem eigenen Ende an — und der besteht durchgehend, egal was am anderen Ende passiert. In diesem Aufbau war das später genau der Fall. Das Äquivalent ist dann die Ethernet-LED am Adapter in der Schublade.

Zur Router-Oberfläche kommt man über das Standard-Gateway:

route -n get default | grep gateway

Die angezeigte IP im Browser aufrufen. Bei TP-Link geht auch http://tplinkwifi.net, bei einer FritzBox http://fritz.box, bei einer Speedport http://speedport.ip.

Der zweite Fall: wenn das eigene Messwerkzeug lügt

Das ist der lehrreichste Teil der ganzen Geschichte. wakelaptop funktionierte direkt nach dem Herunterfahren oder Zuklappen. Nach mehreren Stunden nicht mehr. Der Verdacht lag also auf einer Zeitkomponente — irgendetwas verändert sich, während der Rechner ruht.

Zwei plausible Fährten, beide falsch

A — Deep Sleep beziehungsweise ErP im BIOS. Viele Geräte kappen im ausgeschalteten Zustand nach einer Weile die Reststromversorgung. Die BIOS-Einträge heißen Deep Sleep Control oder ErP / EuP Ready, letzterer existiert wegen der EU-Vorgaben zum Standby-Verbrauch.

B — Sparmodus des Powerline-Adapters. Viele solcher Adapter gehen selbst in Standby, sobald das angeschlossene Gerät den Ethernet-Link verliert.

Beide passten perfekt auf das Zeitmuster. Beide waren falsch. Aber der Weg dorthin ist der eigentliche Inhalt.

Messen statt raten

Ein Fehler, der nur „manchmal“ auftritt, ist kein Fehler — er ist eine ungemessene Variable. Also entstand ein kleines Werkzeug, das jeden Weckversuch protokolliert: Zeitstempel, Ergebnis, und die Zeit seit dem letzten bestätigten Kontakt.

Technisch interessant daran ist die Frage, wie man einen Rechner findet, dessen IP-Adresse man nicht kennt: alle 254 Adressen des Subnetzes parallel anpingen, danach die ARP-Tabelle nach der bekannten MAC-Adresse durchsuchen. Ein Ping erzwingt die ARP-Auflösung, und die MAC-Adresse ist die einzige Konstante, die man bei einem DHCP-Client sicher hat.

Ein Detail zum Stolpern: macOS kürzt in der Ausgabe von arp -an führende Nullen in den Oktetten. Aus aa:bb:cc:0d:ee:ff wird aa:bb:cc:d:ee:ff. Wer stumpf nach der MAC-Adresse sucht, findet nichts — die Oktette müssen vor dem Vergleich auf zwei Stellen aufgefüllt werden.

Der Denkfehler im Werkzeug

Dann meldete das Werkzeug „Laptop ist bereits online“, während der Rechner nachweislich aus war und Deskflow „connection is dead“ anzeigte. Der Grund stand in den Treiber-Einstellungen der Netzwerkkarte: ARP-Abladen: Aktiviert.

ARP-Offload bedeutet, dass die Netzwerkkarte ARP-Anfragen selbständig beantwortet, während das Betriebssystem schläft. Das ist eine sinnvolle Funktion — sie hält den Eintrag des Geräts in den Tabellen der Nachbarn am Leben. Für die Diagnose heißt es aber: Eine ARP-Antwort beweist nur, dass die Netzwerkkarte Strom hat. Über den Rechner dahinter sagt sie nichts. Dazu kommt ein zweiter Fallstrick: macOS behält ARP-Einträge etwa zwanzig Minuten im Cache. Ein Eintrag kann also von einem Gerät stammen, das längst weg ist.

Die Korrektur bestand darin, den Nachweis in Stufen zu führen:

Für Stufe 2 genügt ein Verbindungsversuch auf einen Port, den nur ein laufendes Windows bedient — 445, 135, 139 oder 3389. Erst diese Unterscheidung machte die Messreihe aussagekräftig. Und erst sie zeigte, dass die Karte die ganze Zeit erreichbar war, während der Rechner nicht hochkam. Damit waren Verdacht A und B beide erledigt: Strom und Übertragungsweg funktionierten einwandfrei.

Die tatsächliche Ursache

Zwei Dinge kamen zusammen, beide zeitabhängig — was erklärt, warum es kurz nach dem Zuklappen funktionierte und Stunden später nicht mehr.

1. Windows schläft nicht auf einer Stufe. Im Netzbetrieb wechselt es nach einigen Stunden vom Standby (S3) automatisch in den Ruhezustand (S4). Das ist für Wake-on-LAN ein anderer Zustand mit anderen Voraussetzungen. Abschalten:

powercfg /change hibernate-timeout-ac 0

2. Die Energiesparfunktionen des Netzwerktreibers. Der Blick in die erweiterten Adapter-Einstellungen zeigte drei aktive Funktionen, die Wake-on-LAN untergraben — und zwar typischerweise nicht sofort, sondern nach längerer Ruhe:

Set-NetAdapterAdvancedProperty -Name Ethernet -DisplayName "Power Saving Mode" -DisplayValue "Deaktiviert"
Set-NetAdapterAdvancedProperty -Name Ethernet -DisplayName "Green-Ethernet" -DisplayValue "Deaktiviert"
Set-NetAdapterAdvancedProperty -Name Ethernet -DisplayName "Energy-Efficient Ethernet (LAN-Energiesparen, EEE)" -DisplayValue "Deaktiviert"

Bemerkenswert daran: Die eigentlichen Wake-on-LAN-Optionen waren die ganze Zeit korrekt gesetzt. Wer nur diese prüft, findet nichts und sucht an der falschen Stelle weiter.

Ehrlich eingeordnet: Da beide Änderungen gleichzeitig gemacht wurden, ist nicht bewiesen, welche der beiden die Ursache war. Sie einzeln zurückzunehmen wäre der saubere Weg gewesen, war hier aber die Mühe nicht wert.

Das dritte Symptom: dunkler Monitor

Nach einem erfolgreichen Wecken blieb der externe Monitor zunächst schwarz, obwohl der Rechner lief. Windows behandelt ein Aufwachen per Netzwerk als unattended wake — ohne Benutzer anwesend. Es fährt hoch, lässt das Display aber aus und legt sich nach zwei Minuten wieder hin, wenn keine Eingabe kommt. In der Praxis fällt es kaum auf: Sobald der Mauszeiger vom Mac herüberwandert, zählt das als Eingabe, und das Bild kommt.

Aus einem Shell-Skript wird eine App

Ein hübsches Nebenthema zum Schluss. Eine macOS-Anwendung ist nicht mehr als ein Ordner mit der Endung .app und drei Dingen darin:

Wake Laptop.app/Contents/Info.plist
Wake Laptop.app/Contents/MacOS/WakeLaptop      (ausführbares Shell-Skript)
Wake Laptop.app/Contents/Resources/AppIcon.icns

Kein Xcode, keine Projektdatei. Rückmeldungen gibt das Skript über osascript -e 'display dialog ...' und display notification. Danach lässt sich das Ganze ins Dock legen und wie jedes andere Programm anklicken. Zwei Fallstricke beim Nachbauen: Ein Editor, der die Datei neu schreibt (etwa sed -i), löscht das Ausführungsrecht — ohne chmod +x startet die App wortlos nicht. Und unsignierte Apps dürfen oft keine Systemmitteilungen anzeigen; wenn ein Programm scheinbar nichts tut, lohnt der Start direkt aus dem Terminal, wo Fehlermeldungen sichtbar werden.

Fehlerkatalog

Die Kurzfassung zum Nachbauen

1. Deskflow auf beiden Rechnern in derselben Version installieren. Auf dem Mac den Tap vertrauen, sonst bricht die Installation ab.
2. Auf dem Mac die drei Berechtigungen erteilen: Bedienungshilfen, Eingabeüberwachung, lokales Netzwerk.
3. Layout im Server-Dialog bauen, Screen-Namen exakt nach hostname. Keine Aliase, die sich nur in der Schreibweise unterscheiden.
4. TLS auf beiden Seiten gleich einstellen — beide an oder beide aus.
5. Modifier-Tasten pro Screen umbiegen, wenn die Mac-Kürzel drüben gelten sollen.
6. Auf Windows den Hintergrunddienst plus „Always run as system“ aktivieren, sonst bleiben UAC-Dialoge und Anmeldebildschirm taub.
7. Für Wake-on-LAN: Kabel statt WLAN, Schnellstart aus, Wake on Magic Packet und Shutdown-WoL im Treiber an, BIOS-Option prüfen — und die Energiesparfunktionen des Adapters abschalten.

Was offen blieb

• Das Scrollgefühl. Nicht lösbar, und zwar aus einem Formatgrund, nicht aus einem Konfigurationsgrund.
• Welche der beiden Maßnahmen das Wecken repariert hat. Ruhezustand und Treiber-Sparfunktionen wurden gleichzeitig abgeschaltet.
• Der Heartbeat-Wert. Nach dem Aufwachen hält der Server kurz die tote Verbindung und weist den zurückkehrenden Client ab. Das kostet ein paar Sekunden und ließe sich abkürzen — wurde nicht gemacht, weil es sich von selbst löst.
• Der Anmeldebildschirm nach dem Aufwecken. Funktioniert mit laufendem Dienst, wurde aber nicht über längere Zeit unter allen Bedingungen erprobt.

Fazit

Der Aufbau tut, was er soll: Eine Tastatur, ein Trackpad, zwei Rechner — und die Schublade bleibt zu. Der Weg dorthin war aber weniger eine Installationsanleitung als eine Reihe von Lektionen, die über den Einzelfall hinausgehen.

Wer eine Konfigurationsdatei bearbeitet, sollte wissen, wer sie schreibt. Windows' Rechte-Isolation erklärt mehr Merkwürdigkeiten, als man denkt. Manche Grenzen sind Formatgrenzen und keine Bugs. Ein sporadischer Fehler ist keine Laune, sondern eine ungemessene Variable. Und die unangenehmste Erkenntnis: Auch das eigene Messwerkzeug kann lügen — die ARP-Antwort einer schlafenden Netzwerkkarte sah exakt aus wie ein laufender Rechner.

Jede Diagnose braucht deshalb dieselbe Gegenfrage: Was genau beweist diese Beobachtung — und was nicht?

Quellen

• Deskflow auf GitHub
• Homebrew-Tap
• Wiki: Running on macOS
• Wiki: Workarounds
• Issue #8183 — UAC und Elevate-Modus
• Issue #7132 — Scroll-Geschwindigkeit