There was an error while loading. Please reload this page.
Remote Desktop, Vibe: anonymize the example hosts The `syn-remote add` example named a real machine on a real LAN — its address, its connection name and the account it logs in as — and this page is mirrored onto the public site. Now `desktop` at 192.168.1.50 with `<user>`, matching the `<name>` placeholder style already used further down the page. Vibe's synapd bridge example loses its real last octet too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BkmVYa36M4yjYoobqgmhh9
Settings: the Network pane, and the status is beta now The panes table said "interfaces, radios, firewall" and that is what the pane was. It has addresses now: a hardware address per interface and the addresses each one holds, with a single gateway row and a single nameserver row. The new section walks all four kinds of row and says why the link-local address is not among them. The MAC is the one Remote Desktop needed a home for — a magic packet is addressed to a hardware address, so `syn-remote wake` on the far machine needs what this pane prints. That page now names both places to read it. Status: beta at 0.3.x, and daily-driving it is the recommendation rather than the thing to be talked out of. The note about upgrading from an ISO older than 0.2.3 is retired on Home and at the top of Updating; that page's own account of why syn-update exists is untouched.
Remote Desktop: waking the machine, not just the screen The "machine is suspended" case said it wanted `ethtool -s <iface> wol g` from a boot-time unit. It has commands now: `syn-remote wakeable [on|off]` on the machine that sleeps, `syn-remote wake <name>` on the machine you are sitting at, and `connect` doing it by itself when the machine is not answering. Both halves of arming it are written up, because both are needed and they fail differently: NetworkManager remembers the flag across a reboot, a replug and a driver that clears it on link-down, and a helper applies it now without activating the connection you are reaching the machine over. Which is armed now and which will still be armed after a reboot are reported separately. And the two things that are true however well it is set up: reading the flag needs privilege because the same call can return a SecureOn password, and a magic packet is a broadcast that does not cross a router. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012JixXRpRVg1e69XoQiXxpU
Remote Desktop: reaching it from outside the LAN, and the two walls in the way Neither of them is `syn-remote listen lan`, which only decides what the server binds to — and the knob a person reaches for, `synnet --allow`, is an UNBLOCK that opens nothing. Says so, with the verb that does (`synnet --open`). The second wall is the certificate: it is built from the addresses this machine HOLDS, so a public IP in front of a port forward, or the DDNS name resolving to it, fails with "IP address mismatch" / "Hostname mismatch". `syn-remote names add` is the escape hatch, and re-issuing means every pinned client re-trusts. Also a table for which VPN works as shipped. WireGuard on a private range does; Tailscale does not, because 100.64.0.0/10 is not private — the tunnel comes up outbound and every packet inside it is then dropped, with nothing in any log mentioning the firewall. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V6AAnEY6PXeFWMLdZeFCQC
Remote Desktop: the client half, and why a first connection cannot complete pkgrel 3 shipped saved connections, a pinned certificate per host and a viewer of our own, and the page documented none of it — it still described only the serving side. The gap that matters is the certificate. wayvnc offers exactly one security type this viewer speaks (VeNCrypt X509Plain), so the server's certificate is the first thing in the exchange; until it has been trusted the TLS session comes up and is dropped, and there is NO error on the machine you are sitting at. The only trace is "Client handshake timed out" in the SERVER's journal, which reads like a firewall and is not one. Said with the log line in it, so searching for the symptom finds the cause. Also notes that the server waits for the desktop rather than racing it, since `syn-remote status` reads `Server stopped` for those seconds and that is correct rather than a fault. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V6AAnEY6PXeFWMLdZeFCQC
Remote Desktop: syn-remote, and why the Wayland lore does not apply here