Contact spacedesk Support

Support request: unstable spacedesk session over direct Ethernet (Surface Pro 8 master → iMac M1 viewer) Hello spacedesk support team, I’m requesting assistance with an unstable spacedesk connection between a Surface Pro 8 (master / spacedesk DRIVER) and an iMac M1 (viewer via the HTML5 viewer) over a direct, peer‑to‑peer Ethernet cable. I have a technical background (retired from substation automation and control; currently working on home electronic and embedded design) and am prepared to help reproduce tests, provide logs/pcaps, or participate in troubleshooting. Why this matters and how solving it helps spacedesk Providing a reliable fix for this scenario (peer‑to‑peer Ethernet between a Windows spacedesk DRIVER and the macOS HTML5 viewer on M1 hardware) will streamline installations for users who want a simple, direct second‑monitor setup without a router. Resolving compatibility, NIC setting, or firewall/handshake issues here could reduce support load, improve first‑time success for new users, and increase confidence in spacedesk for mixed platform deskside setups. I’m willing to collect reproducible logs and run tests to produce clear data your QA or engineering team can act on. Summary of the problem Direct Ethernet, Wi‑Fi disabled on both endpoints during tests. Static IPs used: iMac 192.168.2.10; Surface Pro 8 192.168.2.20 (same /24). Observed behavior: the iMac HTML5 viewer connects briefly (SP8 DRIVER shows a pending connection) then the session drops within ~1 second; iMac reports “Network bandwidth is low and screen sharing may be unstable.” The spacedesk listening port on SP8 is 28252 (confirmed via netstat). From the iMac a TCP probe to that port succeeds (nc -vz 192.168.2.20 28252 → succeeded), and SP8 displayed “1 connection pending” when the iMac attempted the connect, but the session still disconnects almost immediately. I observed the same behavior on the iMac under the prior macOS version before upgrading to macOS 14 Tahoe; the upgrade did not change the symptom. What I have already done and confirmed Physical and addressing Confirmed direct Ethernet cable link; Wi‑Fi turned off on both machines for isolated testing. Assigned static IPs on both endpoints in the same subnet (192.168.2.x). Basic reachability and service checks SP8 can ping the iMac. Confirmed spacedeskService is running on SP8 and netstat shows spacedesk bound to TCP port 28252. From the iMac, TCP reachability to SP8: nc -vz 192.168.2.20 28252 → succeeded. SP8 displayed “1 connection pending” at that time. Windows firewall and network profile Enabled inbound ICMP rule for diagnostics and set the SP8 Ethernet profile to Private. Created a temporary inbound allow rule for TCP 28252 and permitted the spacedesk service executable for diagnostic testing. Observations during attempts The iMac viewer briefly displays the remote screen (flicker) then reports low bandwidth and the session terminates in about one second. The behavior is consistent and reproducible with the direct Ethernet link and the above configuration. Diagnostic clues and suspected causes TCP connectivity exists and the server sees the connection request, so basic L2/L3 path and port reachability are present. The immediate teardown suggests either: The spacedesk service is rejecting or terminating sessions after initial handshake; or An application‑level incompatibility between the DRIVER and the HTML5 viewer on macOS (M1 / macOS 14 Tahoe); or Rapid packet loss, MTU/fragmentation, or a NIC offload feature causing the stream to fail immediately after the stream starts. Information I can provide Windows 11 build and exact spacedesk DRIVER version string. macOS 14 (Tahoe) M1 build string and browser/version used for the HTML5 viewer. spacedesk DRIVER console logs for the timestamps showing connect/drop. A short pcap of the iMac↔SP8 traffic capturing the attempted connection to port 28252 (includes TCP handshake and teardown). netstat and arp output from SP8 correlated with timestamps of connect attempts. Specific questions and requests Have you encountered peer‑to‑peer direct Ethernet cases where a session establishes then tears down after ~1 second? Are there known issues with particular NICs, offload settings, or Windows behavior that produce this symptom? Aside from TCP 28252 and the spacedesk service executable, are there additional ports or processes that you recommend whitelisting in Windows firewall for stable sessions? Please provide exact rules, service names, or executable paths. Is the HTML5 viewer fully supported and tested on macOS 14 Tahoe on M1 silicon? Are there any browser-specific caveats (Safari vs Chrome) that could cause immediate disconnects? Do you recommend specific NIC or encoder configuration (MTU, LSO/TSO off, speed/duplex, or encoder profile) for peer‑to‑peer usage to avoid fragmentation or handshake failures? If you want logs or captures, which exact files and formats do you prefer and what timestamps or naming convention should I use when sending them? The DRIVER console on my SP8 shows the trial expires December 31, 2025. I’m not interested in investing substantial time troubleshooting if there’s only a few months of trial availability. If resolving this requires iterative support or access to a beta driver, would spacedesk consider a trial extension or temporary beta access so I can continue diagnosing and produce reproducible results for your QA team? Offer to assist I can run specific captures, paste logs, or execute netstat/tcpdump commands you request and attach the outputs. I’m willing to reproduce the failure modes on request and provide detailed test results to help you trace and fix the issue. Regards, Robert