112 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Aleksandr BogomiakovandClaude	2f7f9980c7	Tray: open the devices window wider and let its table scroll sideways ... Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-02 23:05:08 +01:00
Aleksandr BogomiakovandClaude	2e178a6f9d	Tray: About window, fixed-width device table with totals; WTFPL ... Add an About window (client and agent details, protocol versions), pin the device table's column widths and add a total row, show the version in the header and drop the refresh button. Relicense under WTFPL. Co-Authored-By: Claude <noreply@anthropic.com> v0.1.0-rc.17	2026-10-02 20:16:01 +01:00
Aleksandr BogomiakovandClaude	f4dcdec662	Tray: separate tray and window processes; device list without self ... The tray process holds only the icon and starts the same binary with --window on Open; the window ends when closed, which works on Wayland where a window cannot be hidden. The devices table now names devices as hostname (id5), leaves out this device and counts the others. Co-Authored-By: Claude <noreply@anthropic.com> v0.1.0-rc.16	2026-10-02 19:23:06 +01:00
Aleksandr BogomiakovandClaude	69310108f4	Remember the last hostname each peer announced ... Persist announced hostnames per network (state schema 5) and report them for members, so a device that is away is still named in `status` and the tray. Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-02 19:23:06 +01:00
Aleksandr BogomiakovandClaude	e7dff34ec2	Status: ask the agent for its state directory and its own CAP_NET_ADMIN ... The CLI reached a packaged service's socket but read state from its own default directory, so `network` saw nothing next to a running network, and `status` reported the CLI binary's capabilities instead of the agent's. Co-Authored-By: Claude <noreply@anthropic.com>	2026-10-02 18:31:01 +01:00
Aleksandr BogomiakovandClaude	a55ea883a1	Tray: initialise GTK and run its main loop on Linux ... tray-icon needs gtk::init() and a running GTK loop on Linux, which eframe/winit never provide, so the tray panicked at startup with "GTK has not been initialized". Build the tray on a dedicated GTK thread instead. Co-Authored-By: Claude <noreply@anthropic.com> v0.1.0-rc.15	2026-10-02 17:54:38 +01:00
UltradesuandClaude Opus 4.8	3e066f991f	CI: install libxdo-dev for the Linux tray link ... The x86_64 Linux tray failed at link with "unable to find library -lxdo": tray-icon pulls libxdo, whose .so was not present. Add libxdo-dev to the GUI build's apt install, alongside libgtk-3-dev and libayatana-appindicator3-dev. Everything else (aarch64 agent, macOS, Windows) already built. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.14	2026-10-02 16:51:53 +01:00
UltradesuandClaude Opus 4.8	3752419075	CI: build the Linux tray natively with GTK; drop the aarch64 GUI ... The aarch64 GUI cross-build failed: tray-icon links GTK and libappindicator through pkg-config, which zig cross-compilation cannot satisfy without a target sysroot. Rather than set one up, the Linux tray is now built natively on the x86_64 runner with libgtk-3-dev and libayatana-appindicator3-dev installed, so pkg-config just works. The agent is still static musl for both arches. The aarch64 Linux GUI is dropped for now: that archive stays agent-only and no aarch64 tsunagi-gui package is produced. x86_64 gets the tray in its archive and the tsunagi-gui .deb/.pkg.tar.zst. macOS and Windows build the tray natively as before. Guarded on matrix.gnu_target (set only on x86_64 Linux). Note: the native build links the runner's glibc, so the Linux GUI binary needs a reasonably recent glibc; fine for current desktops. A lower baseline would need a GTK sysroot or an older runner image. YAML validated; the Linux GUI build is exercised only by a real CI run. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.13	2026-10-02 16:38:58 +01:00
UltradesuandClaude Opus 4.8	f63343a6a0	CI: ship the tray GUI — in the archives and as tsunagi-gui deb/zst ... Adds the tray application to the release: - Every target's archive now also contains the tsunagi-tray binary. On Linux it is built against an old glibc baseline (via cargo-zigbuild) rather than static musl, because a GUI must dlopen libGL/X11/Wayland at runtime and a static musl binary cannot; the agent stays static musl. macOS and Windows build the tray natively. - New GUI package variants for Linux: `tsunagi-gui` .deb and .pkg.tar.zst, built by the existing scripts with an extra tray argument. They install the agent (service, polkit, user — same as the headless packages) plus the tray binary, a desktop launcher (dist/linux/tsunagi-tray.desktop) and an icon (dist/linux/tsunagi.svg), so the GUI appears in the applications menu. The GUI package conflicts/replaces/provides the headless tsunagi so the two do not coexist. - The tray finds the system service with no configuration: the library's default control-socket path now prefers /run/tsunagi/agent.sock when present (both the tray and CLI use this), falling back to the per-user path. No control-protocol change. Builds, fmt and clippy clean on macOS; the Linux GUI cross-build and the packages are exercised only by a real CI run. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.12	2026-10-02 16:26:45 +01:00
UltradesuandClaude Opus 4.8	d13bb00623	Tray: one device table (online + offline), FQDN copy, green-fade copy feedback ... - The devices window now shows a single device table instead of a separate "connected" box and an easily-missed "offline" box below it. Every endpoint known from a live tunnel or the signed membership appears, online first; offline rows show name and address with dashes for the live columns. The table fills the window and scrolls, so nothing hides off the bottom. - Clicking an online peer's name copies hostname.network (the FQDN) so it resolves; a name without a hostname copies its short id. - Copy feedback no longer appends "Copied" text (which reflowed the table for a second). The field just flashes green and fades back over a second, with no change to its text or width. Builds and is clippy-clean (-D warnings) on macOS; not run in this headless session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 16:09:33 +01:00
UltradesuandClaude Opus 4.8	2a0a8abd60	Tray: split rate/plot columns, add unit toggle to the devices window ... The connected-peers rate and sparkline shared one grid cell, so the plot still moved right as the rate text grew (e.g. "1.0 kB/s"). They are now two separate grid columns — the plot column starts at the same x on every row, since grid columns align. The devices window also gets its own pkts/bytes toggle, bound to the same unit setting as the main window so the two stay in step. Builds and is clippy-clean (-D warnings) on macOS; not run in this headless session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 16:04:39 +01:00
UltradesuandClaude Opus 4.8	db01c58a6f	Tray: Phosphor icons, click-to-copy fields with feedback, steady plot column ... - Bundle egui-phosphor (pinned to egui 0.31) and register its glyphs, so the icon buttons render real icons instead of tofu: refresh, shuffle (generate secret), pencil/check/x (rename host), copy (Copy secret). - Copying is now the field itself, not a separate button: clicking the shortened device id, the network name, the network id, a range or an address copies the full value and the field flashes green "Copied" for a second (tracked in egui temp memory, so it clears itself). The standalone copy buttons are gone. - In the devices window the connected-peers "rate / plot" column put the rate and the inline sparkline in a shared row, so the plot shifted as the rate text changed width ("0 B/s" vs "1.1 kB/s"). The rate now sits in a fixed-width, truncating cell, so the plot stays put. Builds and is clippy-clean (-D warnings) on macOS; the UI has not been run in this headless session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 16:00:23 +01:00
UltradesuandClaude Opus 4.8	de56258eb1	Tray: copy a network secret via ipc; use text buttons, not missing glyphs ... Two fixes. Secret copy: a new local control request returns a configured network's secret in its tsn1 text form, so the tray's "Copy secret" button can put it on the clipboard. The agent reads it from local state (same source as the CLI's `network secret show`); it crosses only the owner/group socket and is wrapped in a RedactedText type whose Debug prints "<redacted>", so it can never land in a log. In the GUI the worker fetches it and hands it to the UI thread (which owns the clipboard) through a one-shot slot kept out of the status snapshot, so it is copied once and never stored in the cloned snapshot. Control protocol bumped 16 -> 17. Icons: the button glyphs (⧉ ⟳ ✎ ✔ ✕) are not in egui's bundled fonts and showed as tofu squares, so they are now plain text: copy / refresh / random / edit / save / cancel. No icon font to embed. Checks: fmt, clippy --workspace --all-targets -D warnings, and the tsunagi lib, tsunagi-cli and wg-quic local_control tests pass on macOS. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 15:48:32 +01:00
UltradesuandClaude Opus 4.8	8f5ce21ce9	Tray: devices window, bytes/packets toggle, copy & edit affordances ... Replaces the in-tile collapsing peer list with a "Show devices" button that opens a separate, normal-sized window per network, and fills in the rest of the feedback. Main window: - A global show: pkts/bytes toggle; all rates and sparklines follow it. - Sparklines now reserve their space always (fixed height, "no data yet" placeholder) so the layout no longer jumps when data arrives, and each one overlays its peak (top-left) and current value (bottom-right) with units. - Device id has a copy button; the hostname is editable in place (✎ → edit → ✔/Enter sends SetHostname); network name, range and address copy on click. - The Leave button is a neutral red. Per-tile "Show devices" opens the detail. Devices window (a separate egui viewport per network): - Network summary: id (copy), active/broadcast, range, this device's address, candidates, relay fwd/via/recv, dial/handshake failures. - A larger network traffic sparkline. - Connected peers in a table: hostname when known (else short key), protocol, address, handshake age formatted (s/m/h/d), tx/rx packets, tx/rx bytes, and current rate with an inline sparkline. Names and addresses copy on click. - Offline members listed below with address and failed-dial count. Agent: a SetHostname command (over the existing ipc) backs the in-place rename. Traffic sampler now tracks both packet and byte rates; the toggle selects which. Deferred: a "copy secret" button on the tile — the secret is deliberately not exported to the GUI (secrets never leave the agent), so it needs a small local secret-export ipc, which is the next step. Builds and is clippy-clean (-D warnings) on macOS; the UI has not been run in this headless session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 15:37:08 +01:00
UltradesuandClaude Opus 4.8	0a344c1b4f	Report per-peer byte counters, not just packets ... The overlay peer report carried packet counts only, so the GUI could show packets/s but no byte throughput. Adds tx_bytes/rx_bytes to OverlayPeerReport and fills them from each data plane: - the wg and wg-quic plugins already counted plaintext bytes per peer; the CLI now maps them into the report; - the generic tunnel (tcp-tls) gains tx_bytes/rx_bytes on its peer state and report, incremented by the plaintext length at the same points it counts packets. The local control protocol version is bumped (TSN 15 -> 16) since the report shape changed; a client and agent on different builds already detect and report the mismatch. Checks: fmt, clippy --workspace --all-targets -D warnings, and the tsunagi lib, tsunagi-cli and wg-quic local_control tests pass on macOS. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 15:30:37 +01:00
UltradesuandClaude Opus 4.8	2cda56e1f8	Log inbound handshake rejections at debug, not warn ... Creating and leaving networks produced a stream of WARN lines like "Handshake rejected: peer requested an unknown or inactive network network=None". This is not a leave bug: leaving deactivates the network and publishes a release, but remote peers that still consider this device a member keep dialing, and each dial for a network no longer served is correctly rejected by the responder (lookup returns None, so the network stays unidentified — network=None by design, since a pre-handshake claim is unverified). Such a rejection is routine and remotely triggerable — a left network a peer has not caught up on, a stranger, a port scan, an old client — so logging it at WARN let any peer spam the log. It is now debug; enable debug to see rejections when diagnosing. The rejection behaviour itself is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 15:27:49 +01:00
UltradesuandClaude Opus 4.8	d1de61ba29	Tray UI: start hidden, fixed window, grid layout, traffic + peers ... Reworks the tray window per feedback and fills it in. - Starts hidden in the tray (no window on launch); the window opens from the menu. On macOS the app now uses the Accessory activation policy, so it lives in the menu bar with no Dock icon (via a winit event-loop hook, pinned to eframe's winit). Fixed, non-resizable 360x600 window; the layout targets it. - Tidied layout: top bar (title + refresh), a bottom panel with the join form and the action banner, and a scrolling list of network tiles between them. Labels and values sit on two-column grids so they align; the join name and secret inputs are the same fixed width. - A ⟳ button beside the secret generates a fresh random secret (NetworkSecret::generate), for creating a network. - Each network tile shows id, range, this device's address, peers (connected/known), the active and broadcast switches, a Leave button, and a collapsing "peers (N)" section with a formatted per-peer table (short key, address, handshake age, tx/rx packets, rate). - Traffic: a new sampler turns the agent's cumulative packet counters into a packets-per-second rate per network and per peer, from the deltas between snapshots (the snapshot now carries a generation and timestamp so each refresh is sampled once). The network tile shows the current rate and a small hand-drawn sparkline of recent rates (no extra dependency). Note: rates are packets/s — the report has no byte counters yet; bytes would need an agent change. Builds and is clippy-clean (-D warnings) on macOS; the UI has not been run in this headless session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 15:08:29 +01:00
UltradesuandClaude Opus 4.8	19509dc833	Add the tsunagi-tray GUI (egui) — first increment ... A native, lightweight tray application to manage a running agent — no web engine. It is a thin client over the agent's local control socket, reusing tsunagi::ipc and the report types directly; it owns its own runtime, logger and event loop, like the CLI. This first increment: - tray icon with an Open/Quit menu (tray-icon); menu events are read on a background thread so Open works even while the window is hidden; - a small window that hides to the tray on close and reopens from the menu; - a background tokio worker that polls status every 2s and runs commands off the UI thread, writing a snapshot the UI renders from and repainting egui; - UI: device header, a per-network card (name, id, range, this device's address, peers connected/known, a Leave button, and the per-network active and broadcast switches), a join form (name + secret), and a transient action/error banner; an "agent unreachable" state that names the socket. Socket resolution: TSUNAGI_CONTROL_SOCKET if set, else the platform default (/var/run/tsunagi/agent.sock on macOS) — the same socket the group-access agent serves. Scope/notes: macOS first (Linux and Windows follow). Not yet done — macOS accessory activation policy (so there is no dock icon), light/dark tray icons from assets (the icon is drawn in code for now), and packaging/autostart. Builds and is clippy-clean (-D warnings) on macOS; the UI itself has not been run in this headless session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 14:48:52 +01:00
UltradesuandClaude Opus 4.8	de8e48bee7	Let the agent grant the control socket to a group (0660) ... For a GUI (or a CLI) running as a different user to reach the agent, the control socket needs to be group-accessible. This is set by the agent when it binds the socket — correct from creation, not patched afterwards. - ipc::ControlSocketAccess { Private, Group(gid) }. Private is the existing owner-only 0600. Group sets the socket's group to the gid and mode 0660, and creates the socket's parent directory 0755 so the group can traverse to it; if the group cannot be set it falls back to owner-only rather than leaving it wrong. The chown uses std::os::unix::fs::chown — no unsafe, no new lib dependency. - ControlSocket::bind takes the access policy (Windows accepts it and keeps its pipe default for now; a pipe security descriptor is a later follow-up). - CLI: `tsunagi up --control-group <name>` (env TSUNAGI_CONTROL_GROUP) resolves the group to its gid via nix (safe wrapper, unix-only dep) and passes Group(gid); without it the socket stays Private. A name that does not resolve is reported, and the socket stays owner-only. - control_socket() now serves the system path (default_control_socket_path) on macOS too, not just Windows: /var/run/tsunagi/agent.sock, a runtime directory the GUI can reach, rather than the owner-only state directory. A custom --state-dir still keeps its own per-user socket. So the packaged/daemon agent runs e.g. `tsunagi up --control-group tsunagi` and a user in that group talks to it; a plain per-user agent is unchanged (0600). Checks: fmt, clippy --workspace --all-targets -D warnings, tsunagi lib tests and the wg-quic local_control tests pass on macOS. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 14:41:58 +01:00
UltradesuandClaude Opus 4.8	8c812e6874	Bump the GitHub workflow actions off deprecated Node 20 ... GitHub now forces actions/checkout@v4, actions/upload-artifact@v4 and actions/download-artifact@v4 (all Node 20) onto Node 24 with a deprecation warning. Move them to the current Node 24 majors — checkout@v5, upload-artifact@v7, download-artifact@v8 — which keep the same inputs and the per-artifact subdirectory layout (merge-multiple defaults to false), so the publish step is unchanged. Only the .github workflow is touched. The .gitea workflow stays on checkout@v4 and the @v3 artifact actions, because Gitea does not support the v4+ artifact backend and may not have Node 24 on its runner image; it also does not emit these deprecation warnings. mlugg/setup-zig has no Node 24 release yet (latest v2.2.1 is still Node 20), so that one warning remains until upstream updates — nothing to change on our side. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.11	2026-10-02 14:01:33 +01:00
UltradesuandClaude Opus 4.8	63178574ce	Package as a dedicated tsunagi user; add Arch packages ... Reworks the Linux packaging so the service runs as an unprivileged, dedicated "tsunagi" user instead of root — the point of a native package is to set things up properly for that OS's users — and adds Arch Linux packages beside the deb. Both package families are built from the already-compiled static binary; nothing is recompiled. Service model (shared systemd unit, dist/linux/tsunagi.service): - User=tsunagi with AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE, so it creates the TUN and binds low ports without root. - StateDirectory/CacheDirectory/RuntimeDirectory give it /var/lib/tsunagi, /var/cache/tsunagi and /run/tsunagi, and the agent is pointed at them (and the socket at /run/tsunagi/agent.sock) through TSUNAGI_* env in the unit. - The polkit rule now grants the resolve1 actions to the "tsunagi" group; the service user is in it, and admins can add themselves. CLI: when no state dir is chosen, the control commands prefer the system service's socket at /run/tsunagi/agent.sock when it exists, so `sudo tsunagi status`/`join` reach the packaged daemon with no flags. A per-user agent (its socket absent from /run) still uses its own. Packaging: - deb (build-deb.sh): postinst now creates the tsunagi system user+group; unit installed to /lib/systemd/system, binary to /usr/bin. - Arch (new dist/arch/build-pkg.sh): a dependency-free .pkg.tar.zst assembled with bsdtar + zstd (no makepkg, no Arch host) — .PKGINFO, a .INSTALL scriptlet that creates the user and reloads systemd, and a gzipped .MTREE; unit to /usr/lib/systemd/system. - The polkit rule moved to dist/linux (shared by deb, Arch and the tarball), and the tarball install.sh now creates the user and installs the unit + rule. - Both release workflows build the deb and the Arch package on the two Linux matrix entries (deb_arch/pkg_arch), install libarchive-tools+zstd for it, and attach both to the release (Gitea API loop / gh). Not exercised in this session: the .deb and .pkg.tar.zst build and install only on Linux (no dpkg-deb/bsdtar+pacman locally); CLI build, clippy, fmt and tests pass, and all shell/YAML is syntax-checked. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.10	2026-10-02 13:46:27 +01:00
UltradesuandClaude Opus 4.8	a3856eed3b	Build a dependency-free .deb and attach it to the release ... Adds a Debian package to the release for the x86_64 and aarch64 Linux builds, so `apt install ./tsunagi_*.deb` is a convenient path on the Ubuntu hosts. Because the binary is static musl, the package declares no Depends — it is built with plain dpkg-deb on the runner (no cargo-deb or nfpm), from dist/deb/build-deb.sh. The package installs: - the static binary at /usr/bin/tsunagi; - a systemd service at /lib/systemd/system/tsunagi.service that runs the agent as root (ExecStart rewritten to /usr/bin; the source unit targets /usr/local/bin for the tarball installer); - a polkit rule at /usr/share/polkit-1/rules.d granting the resolve1 actions to a "tsunagi" group, for running the agent as a non-root user instead of via the root service. postinst creates that system group and runs daemon-reload; prerm disables the service on removal. Both release workflows gain a "Build the Debian package" step on the two Linux matrix entries (deb/deb_arch), include the .deb in the uploaded run artifacts, and attach it to the release (Gitea via the API loop, GitHub via gh). macOS and Windows are unchanged. Service runs as root by default; the polkit rule/group is the documented opt-in for the non-root path — say if you'd rather the service itself run as the tsunagi user. YAML and shell syntax validated; the .deb build itself runs only on the Linux runner (no dpkg-deb locally) and has not been exercised in this session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.9	2026-10-02 13:34:33 +01:00
UltradesuandClaude Opus 4.8	eac54f8c79	Revert the GitHub workflow guard to server_url ... Misdiagnosed the earlier report: Gitea was correctly running its own .gitea/workflows copy, not this .github one, so the server_url guard was fine. The switch to a GITHUB_RELEASE repo variable then made the workflow skip on GitHub itself, since that variable is not set there. Put both job guards back to `github.server_url == 'https://github.com'`, which runs on GitHub with no manual setup and skips on Gitea (its .gitea copy is the one that runs). No repository variable is needed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.8	2026-10-02 12:53:26 +01:00
UltradesuandClaude Opus 4.8	a8dfd7017b	Gate the GitHub release workflow on a repo variable, not server_url ... The github.server_url guard did not keep this workflow from running on Gitea: Gitea reports github.server_url as https://github.com, so the condition was true there too and the jobs ran (and would fail on @v4/gh). Switch both job guards to `vars.GITHUB_RELEASE == 'true'`, a repository variable set only in the GitHub repo's settings. It is deterministic: absent on Gitea, so the jobs skip there and the .gitea workflow is the one that runs; present on GitHub once configured, so it runs there. The header documents how to set it (Settings → Secrets and variables → Actions → Variables → GITHUB_RELEASE=true). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.7	2026-10-02 12:50:04 +01:00
UltradesuandClaude Opus 4.8	99f4cf0220	Add a GitHub release workflow alongside the Gitea one ... Gitea and GitHub need different release plumbing, so each gets its own file: the Gitea workflow stays in .gitea/workflows, and this GitHub one lives in .github/workflows. The build half is identical (static musl Linux via cargo-zigbuild, native macOS aarch64 and Windows x86_64); only publishing differs — GitHub uses the v4 artifact backend and `gh release create`/`upload`, which the Gitea file cannot use. Because Gitea reads both .gitea/workflows and .github/workflows, every job here is guarded with `if: github.server_url == 'https://github.com'`, so on Gitea this file's jobs are skipped (no v4/gh failures) and the .gitea file is the one that runs. GitHub never reads .gitea, so there it runs only this one. Publish is re-run safe: it creates the release on the first run and uploads with --clobber onto an existing release afterwards; a pre-release suffix on the tag marks it prerelease. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.6	2026-10-02 12:47:19 +01:00
UltradesuandClaude Opus 4.8	69263b2dd9	Move the release workflow to .gitea/workflows ... The release pipeline is Gitea-specific (v3 artifacts, Gitea release API), so it must not run on github.com, where it would fail. GitHub only reads .github/workflows, while Gitea reads both, so moving the file to .gitea/workflows keeps it running on Gitea and invisible to GitHub. A separate GitHub-flavoured release workflow can be added under .github later. The portable .github/workflows/ci.yml (fmt/clippy/test) is left in place; it works on both and is not what this change is about. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.5	2026-10-02 12:13:45 +01:00
UltradesuandClaude Opus 4.8	20444013c0	Split release into build artifacts + a publish job (Gitea) ... The direct-upload-from-each-build approach failed ("Upload the archive to the release" exit 1) and left no artifacts to inspect. Restructured into the familiar shape: build jobs now leave their archive as a run artifact, and a single publish job — gated on all targets succeeding — collects them and fills the release. - Build jobs use actions/upload-artifact@v3 (Gitea has no v4 backend; v3 is what shows under the run), so the archive is visible and handed on. - publish (needs: build) downloads everything with download-artifact@v3 and uploads each archive to the Gitea release with curl, once, with no matrix race. It prints the API base and the HTTP status/body of every call, so a failure (e.g. a read-only Actions token → 403, or a bad API URL) is now visible in the log instead of a bare exit 1. - Release API base prefers GITHUB_API_URL (Gitea sets it to its /api/v1 root) and falls back to GITHUB_SERVER_URL/api/v1. Asset uploads run in the main shell via process substitution so a failed upload fails the job. Build, package, musl/zig setup and the target matrix are unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 12:12:53 +01:00
UltradesuandClaude Opus 4.8	2196f6635b	Quiet the cosmetic zig linker_messages warning on the musl build ... The musl release build now links cleanly through cargo-zigbuild, but rustc's new linker_messages lint echoed zig's "ignoring deprecated linker optimization setting '1'" note — zig's linker declining the -O1 GNU-ld flag Rust passes. It is cosmetic and the binary is correct, so allow that one lint, scoped to the zig build step only. macOS and Windows keep full linker diagnostics, and a real link error still fails the build. No behaviour change to the produced binaries; takes effect on the next tag. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 12:06:04 +01:00
UltradesuandClaude Opus 4.8	6438982d45	Upload release assets via the Gitea API instead of artifacts + gh ... The release ran on Gitea Actions, where it failed at actions/upload-artifact@v4: the v4 artifact backend (and the GitHub REST API that `gh release create` uses) are not available on Gitea/GHES, so both the artifact handoff and the publish job were dead ends there. Reworked so each build job uploads its archive straight to the release through Gitea's native API (`/api/v1/repos/<repo>/releases`) with curl: create the release for the tag if absent (races between matrix jobs are resolved by reading the id back by tag), then POST the archive as an asset. The separate publish job, download-artifact and `gh` are gone. The id is parsed with grep, so the runner needs only curl and coreutils — no jq, no third-party release action. Uses the Gitea-injected GITHUB_TOKEN, GITHUB_SERVER_URL and GITHUB_REPOSITORY; a tag with a pre-release suffix (e.g. -rc.2) is marked prerelease. This targets Gitea by design; it no longer runs as-is on github.com (different API), which is fine — the GitHub build is being retired. Build and package steps, the musl/zig setup and the target matrix are unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.3	2026-10-02 12:04:20 +01:00
UltradesuandClaude Opus 4.8	21b619388c	Pin Zig to a real release so the musl release build fetches reliably ... The release run failed at "Install zig": mlugg/setup-zig, left unpinned, resolved to the newest version it knew of — an unreleased 0.16.0 whose tarball 404s on ziglang.org — and the community mirrors returned 502/503 around it, so the step errored out before cargo-zigbuild ever ran. Pin the action to Zig 0.14.1, an archived release with a permanent official download URL. The official source then succeeds even when the mirrors are flaky, and the version stays compatible with cargo-zigbuild. Also moves the action to @v2. Only the Linux musl jobs use zig; macOS and Windows are unaffected. Not run on a real tag yet in this session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.2	2026-10-02 11:54:29 +01:00
UltradesuandClaude Opus 4.8	d1ab993dd2	Add a tagged-release CI workflow and Linux/Windows packaging ... Pushing a `v*` tag now builds the agent for every supported target and attaches the archives to a GitHub release. Modelled on the furumi release workflow (a build matrix, then a publish job that runs `gh release create`), adapted to this project's two differences: it needs system integration (capabilities/polkit on Linux, elevation+wintun on Windows, a root daemon on macOS), and its users run varied distros, not just Ubuntu. Linux is built as a fully **static musl** binary with cargo-zigbuild, so one artifact runs on Arch, Alpine, NixOS and old-glibc systems alike, and can be repackaged into whatever a distro prefers later. musl has no prebuilt aws-lc-sys bindings, so the Linux jobs install cmake + libclang (bindgen) and zig (the cross C compiler zigbuild drives). macOS (aarch64) and Windows (x86_64) build natively; Linux covers x86_64 and aarch64. Targets: x86_64/aarch64 linux-musl, aarch64 macOS, x86_64 Windows. Each archive carries the binary, the top-level README, and the platform's install notes plus integration files: - dist/linux/: a static-friendly README, a systemd unit (runs as root, so no capability grant or polkit rule is needed; a commented non-root variant is included), and an install.sh that drops the binary and the unit or prints the setcap/polkit alternative. - dist/windows/: install notes covering wintun.dll and Run-as-administrator. - dist/macos/: the existing LaunchDaemon plist and notes, now also shipped in the archive. Not exercised yet: the workflow only runs on a real tag push, and the aws-lc-sys-under-musl build has not been run locally in this session (no zig toolchain here). YAML and install.sh syntax are validated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> v0.1.0-rc.1	2026-10-02 11:48:19 +01:00
UltradesuandClaude Opus 4.8	da7ce1dca1	Drop link-local addresses from the status "not announced" list ... A host with several interfaces has a link-local (fe80::/10, and 169.254/16 on IPv4) on each, and none of them is ever a peer candidate. Listing them under "not announced" padded the section with one noise line per interface — most of the list on a machine with several VPN utuns. They are now filtered out; loopback and real unannounced addresses are unaffected. Checks: cargo fmt --all --check and cargo clippy -p tsunagi-cli --all-targets -D warnings pass; verified by eye against a live `tsunagi status`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 11:38:21 +01:00
UltradesuandClaude Opus 4.8	4d2f8a54ec	Compact the status address list to one line per address ... `tsunagi status` printed every local address as two lines: the address, then an indented note holding the interface (and, for candidates, a priority rank). On a host with many interfaces — common on macOS, where each VPN adds a utun and every interface carries a link-local — that made the "local addresses" section very long and hard to scan. Each address is now a single line: the announce status stays the label (announced / not announced / loopback) and the address and its interface share the detail, as `<addr> · <iface>`. The per-row note and the candidate-priority rank are dropped; ordering still reflects candidate priority. No other section changes, and nothing but the presentation does. Checks: cargo fmt --all --check, cargo clippy --locked --workspace --all-targets -D warnings, and the tsunagi-cli tests all pass on macOS; verified by eye against a live `tsunagi status`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 11:26:13 +01:00
UltradesuandClaude Opus 4.8	c3a6201ee2	Bring the macOS stack up: utun interface, resolver files, system paths ... macOS was TUN-less: the agent ran only with `--no-tun`, so tunnels formed but nothing reached the operating system. The provisioner, host rules and DNS publisher had Linux and Windows implementations and fell through to the unsupported/erroring paths on macOS. This adds the macOS half so `tsunagi up` carries real traffic there. The shared decision logic (plan_changes, rules_summary, Published) is untouched — only the per-platform mechanics are new. What it does on macOS (all root-only; macOS has no per-capability grant): - Interface: a `utun` device opened over the in-kernel utun control socket via the existing `tun` dependency (no kext, no Network Extension). The kernel assigns the `utunN` name, so a name derived from the network id is not a legal utun name; `open_tun` leaves the name unset on macOS and reads the real one back, and `Interface::start` adopts `device.name()` as the name everything downstream configures (host rules, reconfigure). A utun is torn down with the process, so a crash never leaks one. Addresses, MTU, up and the overlay subnet route are applied with `/sbin/ifconfig` and `/sbin/route` (absolute paths, args built only from locally-derived values), the same role netlink plays on Linux and netsh on Windows. Observation is `netdev` (getifaddrs). - DNS: a resolver-dir publisher writes `/etc/resolver/<network>` files pointing the system resolver at the overlay DNS server for each zone. The files carry a `port`, so the server needs no privileged socket, and a marker line, so the publisher only ever replaces or removes files it wrote and never clobbers a user's own. Removed on revert. - Broadcast host rules: the `255.255.255.255` route is installed with `route`. The inbound-UDP firewall allowance (a pf anchor) is deferred and reported as the incomplete half, so `status` says what to allow by hand; the route still goes in. Failure stays contained, exactly as on the other platforms. - Privilege: probe is optimistic (like Windows); the honest answer comes from the utun open, whose permission error now says to run with sudo or as a daemon. Deployment: - Default paths on macOS are fixed system locations rather than per-user Library dirs, so they do not depend on whose shell ran sudo: state `/var/db/tsunagi`, cache `/var/db/tsunagi/cache` (StoragePaths::user_default), control socket `/var/run/tsunagi/agent.sock` (default_control_socket_path, mirroring the Windows %ProgramData% branch). The local control socket already uses the shared `unix` adapter, so no IPC changes were needed — macOS is Unix. - dist/macos/ carries a root LaunchDaemon plist and install notes; README's deployment section now documents the macOS path instead of "not implemented". Decisions (agreed up front): utun auto-assign with the real name adopted; ifconfig/route rather than raw PF_ROUTE/ioctl (which would need unsafe); /etc/resolver files rather than scutil; route-now/firewall-deferred; root via sudo or a LaunchDaemon rather than Network Extension (which would require a signed sandboxed app bundle, not a Rust CLI). Checks: on macOS (Darwin 27), `cargo fmt --all --check`, `cargo clippy --locked --workspace --all-targets -D warnings`, and `cargo test --locked --workspace --all-targets` all pass (0 failures); the new macos-gated unit tests run under the standard workspace command via feature unification. Not yet exercised live: actual utun creation, ifconfig/route application and /etc/resolver writes need a root run, which has not been done in this session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 11:15:59 +01:00
Aleksandr Bogomiakov	533921059a	Install broadcast route and firewall allowance on the host while broadcast is on ... LAN discovery (CS 1.6 and similar) only worked after two manual steps on every host: route 255.255.255.255 through the TUN, and allow inbound traffic on it. Without the route the game's limited broadcast leaves via the physical adapter and never reaches the overlay; without the firewall allowance the server's unicast reply (from a different address than the one the request went to, so never matched by conntrack) is dropped before the game's socket. Verified by hand on Linux: with both in place the server answered A2S_INFO over the overlay. The system level (not a plugin) now installs exactly those two things for the interface it owns, and removes them when broadcast is turned off, the network is left or stopped, or the agent exits. Design: - New boundary overlay::hostrules (BroadcastHostRules: idempotent apply/clear, with Linux, Windows, Mock and Unsupported implementations). TunFactory gains host_rules(); ManagedTunFactory::with_host_rules wires it in the CLI. - Interface::sync_broadcast_rules reconciles the host against the routing table (RoutingTable::broadcast_host_target) and is called after address sync, on live `network broadcast on/off`, on network deactivation and by remove(). Failure is contained: the outcome is kept and logged, never fatal. - One interface carries several networks but the host has one 255.255.255.255 route, so the source is the lowest NetworkId among broadcast-enabled networks with an address (documented in docs/broadcast.md). - Linux: the route is added on the existing netlink thread (preferred source = overlay address, replace semantics). The firewall rule is `iptables -I INPUT -i <if> -p udp -s <overlay range>` tagged with a comment `tsunagi:<if>`; it is UDP-only and range-limited on purpose so TCP services stay unexposed. iptables is located in fixed system directories, never via PATH; stale tagged rules (e.g. from a crash) are replaced. A missing iptables leaves the route in place and is reported. rp_filter is not touched. - Windows: PowerShell (absolute path) New-NetRoute metric 1 and a tagged inbound UDP Defender rule scoped to the interface alias and overlay range. - status shows a `broadcast rules` row (ok, or which half failed and why). IPC control protocol bumped 14 -> 15 because OverlayReport gained a field. - AGENTS.md records the narrow exception to "never touch routing/firewall". Compatibility: restart the agent after upgrading (control protocol 15). No wire or schema change. Checks run (Linux only): cargo fmt --check, cargo clippy --locked --workspace --all-targets -D warnings, cargo test --locked --workspace --all-targets, all passing. Tests use a mock host and a scripted iptables; no OS setting is changed. NOT done: the Windows code was never compiled for or run on Windows (cross-compiling failed for lack of a C toolchain), only its script building is unit-tested; the real netlink route and iptables calls were not exercised against a live kernel in the suite; CS 1.6 was not launched from this change.	2026-10-01 15:03:43 +01:00
Aleksandr Bogomiakov	d2778f0b5a	Prevent WireGuard timer loop failure spam and fix handshake broadcast ... When a WireGuard tunnel handshake timed out or a rekey failed, Inner::on_tunnel_failed closed the transport link and reported the failure to the agent core. However: 1. The peer remained in WireguardDevice::inner.peers. Once boringtun declared ConnectionExpired (after 90s), self.tunn.is_expired() remained permanently true on all subsequent 250ms timer ticks. drive_timers repeatedly detected failed = true every 250ms, flooding logs with 'WARN WireGuard tunnel failed due to rekey timeout, triggering fallback' and sending repeated protocol failure events to the core 4 times/sec. 2. In WireguardLink::send, is_handshake_init incorrectly expected an envelope header offset (msg[74] == 1) when checking for initiation packets, which failed on raw WireGuard UDP packets. As a result, handshake initiations were not broadcast to all candidate endpoints. 3. In WireguardTransport::accept_loop, packet source matching contained dead envelope destination matching inspecting ephemeral key bytes against local endpoint IDs. Fixes: - In crates/tsunagi-wireguard/src/device.rs: - Add failed: bool to FlowTunnel to latch failure state. Once a failure is reported, update_timers returns (TunnResult::Done, false) on all subsequent ticks until a new handshake is started or completed. - In Inner::on_tunnel_failed, remove the failed peer from inner.peers so drive_timers ceases ticking on the dead tunnel. - In crates/tsunagi-wireguard/src/plugin.rs: - In Worker::sync, retain only active unclosed links in state.links. - In crates/tsunagi-wireguard/src/transport.rs: - Check is_handshake_init directly as '!msg.is_empty() && msg[0] == 1', ensuring handshake initiations are broadcast to all candidate addresses. - Clean up matched_peer to look up links and peer candidate addresses directly. - Tests: - Update test_flow_tunnel_rekey_timeout_triggers_failure to assert failure latching and verify no repeated failure reports on subsequent ticks. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed. - cargo build --release passed.	2026-10-01 03:18:32 +01:00
Aleksandr Bogomiakov	8cfece9479	Filter noisy internal warnings from boringtun and iroh net_report ... The CLI's default tracing filter previously allowed WARN level logs from boringtun and iroh, producing two confusing and noisy log messages during routine operation: 1. 'WARN HANDSHAKE(REJECT_AFTER_TIME - KEEPALIVE_TIMEOUT - REKEY_TIMEOUT (on receive))': emitted by boringtun's internal timer tick when an endpoint primarily receives data for 165 seconds (180s - 10s - 5s). In boringtun, this is a routine scheduled rekey timer rather than an error or failure, but was unhelpfully logged as warn! upstream. 2. 'WARN probe timed out': emitted by iroh's net_report module during background HTTP captive portal detection when running in isolated subnets or VMs without direct internet access. This probe has no impact on mesh connectivity. Update the default logging filter to: 'info,iroh=warn,iroh::net_report=error,quinn=warn,rustls=warn,boringtun=error,mainline=off' Real WireGuard handshake and rekey failures continue to be detected and reported cleanly by Tsunagi's own data plane diagnostics and automatic fallback handlers at INFO and WARN levels. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed. - cargo build --release passed.	2026-10-01 03:06:20 +01:00
Aleksandr Bogomiakov	3930dff2dc	Detect WireGuard tunnel rekey failure and trigger automatic fallback ... Previously, because UDP is connectionless, when a pure WireGuard tunnel encountered handshake or rekey failures (e.g. boringtun logging `WARN HANDSHAKE(REKEY_TIMEOUT)` and `CONNECTION_EXPIRED`), the `WireguardLink` never closed. It remained active in `agent.links` and as a direct hop in `RelayHub.raw`. Consequently, outgoing packets continued to be blackholed over the dead direct path, preventing `RelayHub` from using working multihop relay routes and preventing the agent from falling back to alternative protocols (`tcp-tls` or `wg-quic`). Key changes: - In `crates/tsunagi-wireguard/src/device.rs`: - In `FlowTunnel`, track active handshake and rekey attempts via `handshake_started_at`. If an active handshake attempt remains unanswered beyond `HANDSHAKE_TIMEOUT` (15s) or boringtun reports `ConnectionExpired`, declare the tunnel dead. - Reset timeout timers upon successful handshake reception in `decapsulate`. - In `drive_timers`, when tunnel failure is detected, trigger `inner.on_tunnel_failed(peer)`, which closes the direct transport link and notifies the agent via `PluginContext::report_peer_protocol_failure`. - In `crates/tsunagi-wireguard/src/transport.rs`: - Add `WireguardLink::close` to transition `is_closed` to true and notify `closed_notify`. - In `WireguardLink::recv`, select on `closed_notify` so readers unblock and return `None` immediately on close. - Add `WireguardTransport::close_link` to close active links by network and peer. - In `crates/tsunagi/src/dataplane/mod.rs`: - Add `PluginRequest::ProtocolFailure` and public helper `PluginContext::report_peer_protocol_failure`. - In `crates/tsunagi/src/agent/mod.rs` and `crates/tsunagi/src/agent/network.rs`: - Add `NetCommand::ProtocolFailure` to runtime command handling. - On protocol failure: remove dead direct link from `self.links`, clear it from `RelayHub.raw` (so `RelayHub` immediately routes over available multihop relays), record failure on `wg` for that peer with exponential backoff cooldown, emit `DataLinkDown`, and immediately call `ensure_links()` to dial the next mutually supported protocol (`tcp-tls` or `wg-quic`). - Tests: - Add `test_flow_tunnel_rekey_timeout_triggers_failure` and `test_flow_tunnel_reset_on_handshake` unit tests in `device.rs`. - Add `test_wireguard_link_close_and_transport_close_link` in `transport_tests.rs`. - Add `test_protocol_dial_state_cooldown_and_fallback_selection` in `network.rs`. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed (350+ tests passed). - Built release binary: target/release/tsunagi.	2026-10-01 03:02:09 +01:00
Aleksandr Bogomiakov	35acc4d231	Fix WireGuard relay preemption with UDP probing, allow VM bridges, and categorize status addresses ... When remote peers communicate across networks with mixed connectivity (e.g. a remote Linux node, a local Linux host, and a Windows VM guest under KVM): - Previously, `WireguardTransport` immediately created and installed unverified direct links into `RelayHub` in `notify_peer_capability` and `open()`. When a remote peer had only unroutable private addresses (e.g. 192.168.122.151 on a KVM NAT bridge), this dead direct link preempted the working 2-hop relay, causing packet drops, failed handshakes, and REKEY_TIMEOUT errors. - Host-guest VM bridges (`virbr*`) were previously filtered out, preventing the VM guest from discovering the host's bridge IP (192.168.122.1) and forcing it to attempt cross-interface connections to host Wi-Fi/LAN. - Concurrent activation of multiple networks sharing one `tsun0` interface raced in `sync_addresses`, resulting in netlink `File exists (os error 17)` and `The object already exists` on Windows. Key fixes: - In `crates/tsunagi-wireguard/src/transport.rs`: - Implement bidirectional UDP probing with `TSUNAGI_WG_PROBE_V1` PING/PONG. - In `open()`, probe candidate endpoints with retransmission up to 1200ms. If unreachable, return `TransportError::Unreachable`, preventing dead links from preempting valid relay routes in `RelayHub`. - In `notify_peer_capability`, send hole-punching probes without prematurely installing unverified links. - In `accept_loop`, reply to PING probes with PONG and install confirmed inbound links targeting the verified source address. - In `WireguardLink::send`, inspect byte 74 of enveloped packets to detect handshake initiations, ensuring confirmed links route data packets only to the active target. - In `crates/tsunagi-wireguard/src/plugin.rs`: - Permit VM bridges (`virbr*`) as candidate interfaces (priority 10). - Add `prioritize_local_subnet` to prioritize candidates sharing a local IPv4 subnet with the receiver (e.g. 192.168.122.0/24). - In `crates/tsunagi/src/overlay/interface.rs` & provisioners: - Add async mutex `sync_lock` to serialize concurrent address syncs across networks. - Handle netlink EEXIST (os error 17) and Windows already-exists errors idempotently as success. - In `crates/tsunagi-cli/src/main.rs`: - Split `local addresses` in `tsunagi status` into `announced` (candidate addresses in priority order with interface and rank), `not announced` (container bridges/internal addresses with interface name), and `loopback`. - Tests: - Add `test_wireguard_transport_unreachable_probe_times_out` and `test_matches_subnet` unit tests. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed (350+ tests passed).	2026-10-01 02:38:13 +01:00
Aleksandr Bogomiakov	c791102ad9	Fix overlay and virtual interface candidate leakage and WireGuard rekeying ... On Windows (Wintun), iface.name in netdev is an adapter GUID, while iface.friendly_name is 'tsun0'. Checking only iface.name failed to identify and exclude Wintun overlay interfaces. Consequently, Windows nodes announced their own overlay IP addresses (e.g. 10.13.37.26) as candidate endpoints. Remote peers latched onto this overlay IP as the WireGuard target, routing encrypted packets into tsun0 (recursive loop), resulting in failed handshakes and subsequent HANDSHAKE(REKEY_TIMEOUT) and CONNECTION_EXPIRED. Similarly, Docker bridges (br-*, docker0) and virtual bridges were announced and alphabetically sorted before physical LAN or Tailscale interfaces, causing peers to attempt WireGuard handshakes with internal Docker bridge addresses (e.g. 172.21.0.1). Key changes: - In crates/tsunagi-wireguard and crates/tsunagi-tcp-tls: - Robustly identify overlay interfaces by inspecting iface.name, iface.friendly_name, and iface.description for 'tsun', 'tsunagi', and 'wintun'. - Filter out container and virtual bridge interfaces (docker, br-, veth, virbr, cni, flannel, cali, kube, dummy, lxc, podman, vethernet, vboxnet, vmnet). - Prioritize candidates by physical interface score: interfaces with a default gateway (physical LAN/WAN) and Tailscale (100.64.0.0/10) score highest and sort to candidate #0. - In on_peer_capability, filter out any announced address falling inside any active overlay IPv4 range (defense in depth on receiver). - In crates/tsunagi-wireguard/src/transport.rs: - In WireguardLink::send, broadcast Handshake Initiation packets (type 1) to all candidate addresses so initial handshakes and rekeys probe all candidate paths and recover if an endpoint roamed or NAT expired. - In accept_loop, prioritize exact socket address matches before falling back to candidate IP matches for NAT port roaming. - In crates/tsunagi/src/net.rs: - Update iroh AddrFilter to inspect friendly_name and description, preventing Wintun overlay IPs from leaking into iroh discovery endpoints. - Tests: - Add unit tests for candidate interface filtering, IP validation, and priority scoring in tsunagi-wireguard and tsunagi-tcp-tls. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed (350+ tests passed).	2026-10-01 02:15:06 +01:00
Aleksandr Bogomiakov	f80841da63	Fix WireGuard multi-network demux, candidate discovery, and status reporting ... When a peer belongs to multiple overlay networks served by one agent (e.g. a VM participating in both 'hexor' and 'ultradesu'), packets received on the shared WireGuard UDP socket could not be differentiated by source IP/port alone. Previously, `WireguardTransport::accept_loop` picked the first matching link found in iteration order, starving other networks for that peer and causing rekey timeouts (`WARN HANDSHAKE(REKEY_TIMEOUT)`, `ERROR CONNECTION_EXPIRED(REKEY_ATTEMPT_TIME)`) and packet loss on the starved network. Additionally: - When a peer had multiple candidate endpoints (such as LAN, VM bridge, and Tailscale CGNAT addresses), `WireguardLink` sent handshake initiations only to `addrs[0]`. If the first address was unreachable from the remote side (e.g. host's Tailscale IP unreachable from inside a local VM), the handshake never completed. - In `build_report`, peers known to the `wg-quic` plugin were added with empty tunnels even if an active `wg` (pure WireGuard) tunnel existed, causing `tsunagi status` to falsely report 'no WireGuard handshake yet' for connected and pingable peers. - `local_ip_candidates` previously included IPv6 addresses which caused OS error 22 (EINVAL) when passed to the IPv4-bound UDP socket. Key fixes: - In `crates/tsunagi-wireguard/src/transport.rs`: - Store `peer_networks` as `HashSet<NetworkId>` per peer. - In `WireguardLink`, maintain a list of candidate addresses and a `confirmed` flag. Before a handshake response confirms the active path, transmit datagrams (handshake initiations) to all candidate addresses. Upon receiving an inbound datagram, lock onto the confirmed address. - In `accept_loop`, deliver inbound datagrams to all active links associated with the sender's endpoint ID across all networks. Boringtun's cryptographic index and AEAD verification naturally demultiplexes and accepts the packet in the correct network while discarding it in others. - Filter candidate addresses to IPv4 to match the bound socket family. - In `crates/tsunagi-wireguard/src/plugin.rs`: - Only collect IPv4 interfaces in `local_ip_candidates`. - In `crates/tsunagi-cli/src/main.rs`: - Refactor `build_report` to evaluate all protocols per peer and prioritize whichever protocol has an active tunnel (`wg` > `tcp-tls` > `wg-quic`). - In `crates/tsunagi-wireguard/tests/plugin_tests.rs`: - Add `test_wireguard_two_networks_same_peers` verifying simultaneous bidirectional packet transmission between two peers sharing two networks over a single `WireguardTransport`. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed (350+ tests passed).	2026-10-01 01:38:44 +01:00
Aleksandr Bogomiakov	7070a16104	Add pure WireGuard direct UDP data plane plugin and transport ... Peers communicating on uncensored networks can benefit from raw WireGuard performance over direct UDP without QUIC framing or double-encryption overhead. This provides Tailscale-like direct tunnel performance while preserving Tsunagi's decentralized mesh architecture. Key changes: - Create `tsunagi-wireguard` crate implementing the `IpPlugin` and `PacketTransport` contracts: - `WG_PROTOCOL = "wg"` with wire version 1. - Bounded `WgAnnouncement` carrying WireGuard public keys, listening UDP ports, and candidate IP addresses (filtering out overlay interfaces). - `WgKeyStore` managing persistent per-network WireGuard X25519 keys in SQLite with zeroization on drop. - `WireguardTransport` providing direct UDP packet transmission, candidate address tracking, inbound link delivery, and roaming support. - `WireguardDevice` running userspace WireGuard encryption via `boringtun`, timer maintenance, and AllowedIPs source enforcement. - Integrate `wg` into `tsunagi-cli`: - Set default protocols to `"wg,tcp-tls,wg-quic"` so all protocols are enabled by default in order of throughput and performance. - Support `"wireguard"` as a convenience alias for `"wg"` in `--protocol`. - Bind `PureWgTransport` and launch the inbound datagram accept loop on `up`. - Pass `pure_wg` plugin to `AgentControl` and update `build_report` so active WireGuard tunnels and overlay metrics are reported in `tsunagi status`. - Clean up WireGuard keys on network removal in `forget_protocol_state`. - Comprehensive test coverage in `tsunagi-wireguard`: - `announcement_tests`: round-trip serialization and verification of malformed, mismatched network, zero port, or self-claiming announcements. - `transport_tests`: loopback UDP link delivery between transports. - `plugin_tests`: end-to-end two-peer handshake and bidirectional IP packet transit over direct UDP. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed.	2026-10-01 01:24:25 +01:00
Aleksandr Bogomiakov	46575d0899	Prioritize stored agreed range over default range in reserve_range ... When an agent restarted with multiple networks (e.g. hexor and ultradesu), Agent::reserve_range() previously attempted to reserve the default configured range (10.13.37.0/24) for whichever network happened to be listed first in storage, even if that network had already agreed upon a different range (such as 10.79.175.0/24). As a result, the first network seized 10.13.37.0/24 in the route table, causing the second network (which genuinely used 10.13.37.0/24) to trigger a spurious RouteError::Overlap warning at startup until the first network asynchronously loaded its signed records and released the reservation. Key changes: - In crates/tsunagi/src/agent/mod.rs, make reserve_range asynchronous and inspect stored signed records first using StateSet::agreed_range(). - If an agreed range already exists in storage, reserve that specific range in routes immediately instead of preemptively claiming the default overlay_ipv4_range. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets --jobs 2 -- --test-threads=2 passed (349 tests passed).	2026-10-01 00:36:24 +01:00
Aleksandr Bogomiakov	a89e65475d	Implement Debug manually for PipeSecurityAttributes on Windows ... The windows_sys::Win32::Security::SECURITY_ATTRIBUTES struct is a raw C FFI struct that does not implement std::fmt::Debug. Deriving Debug on PipeSecurityAttributes failed Windows compilation with E0277. Key changes: - In crates/tsunagi/src/ipc/windows.rs, remove #[derive(Debug)] on PipeSecurityAttributes and provide an explicit std::fmt::Debug implementation formatting nLength, lpSecurityDescriptor, and bInheritHandle. Validation on Linux: - Verified type check against Windows target via rustc. - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets --jobs 2 -- --test-threads=2 passed (349 tests passed).	2026-10-01 00:31:21 +01:00
Aleksandr Bogomiakov	2ed447ae86	Filter overlay interface from candidates and align status member columns ... Peers previously advertised overlay interface (tsun0) addresses as physical candidate endpoints for both iroh discovery and tcp-tls announcements. When an intermediate tunnel was active between two peers (e.g., between a host and a VM), iroh probes to the remote peer's overlay address were routed through the existing overlay, causing iroh to select the overlay IP itself as a 'direct' endpoint. This caused recursive tunneling (QUIC over WireGuard over TLS) and confusing status output showing peers connecting to their own overlay IP addresses. Additionally, in tsunagi status, peer rows were displayed with unaligned columns, mixing control plane status and data plane metrics in a way that was difficult to scan. Key improvements: - In crates/tsunagi/src/net.rs, add an AddrFilter to the iroh EndpointBuilder to dynamically filter out any local addresses assigned to tsun* overlay interfaces before publishing to address discovery services (DHT/pkarr/STUN). - In crates/tsunagi-tcp-tls/src/plugin.rs, exclude tsun* interfaces from local_ip_candidates() so overlay IPs are never advertised as physical TCP endpoints. - In crates/tsunagi-cli/src/main.rs, exclude tsun* interfaces from netwatch_addresses() so the local addresses section reflects only actual physical/host network interfaces. - In crates/tsunagi-cli/src/main.rs, update member_row() to format member details with aligned columnar layout: the overlay IP is placed first and padded, followed by control plane transport and latency, and line 2 pads tunnel metrics so that the data link endpoint (via ...) aligns vertically. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets --jobs 2 -- --test-threads=2 passed (349 tests passed).	2026-10-01 00:24:53 +01:00
Aleksandr Bogomiakov	ac5a1596ef	Allow unelevated Windows processes to access control socket via SDDL and shared path ... When running the tsunagi agent as an elevated Administrator or Windows Service, unprivileged user-space processes (such as a system tray application, user-level CLI commands, or status monitors) could not interact with the control socket. This was due to two constraints on Windows: 1. The default control socket path was derived from the per-user %APPDATA%, making an administrator's socket invisible or inaccessible to a non-elevated standard user profile. 2. Even if pointed to the same named pipe, Windows Mandatory Integrity Control (MIC) and default ACLs prevent a Medium-Integrity (unelevated) process from opening a High-Integrity (elevated) pipe server for write access unless explicitly allowed. Key changes: - In crates/tsunagi/src/ipc/windows.rs, implement PipeSecurityAttributes using Win32 ConvertStringSecurityDescriptorToSecurityDescriptorW with SDDL: "D:(A;;GRGW;;;WD)(A;;GA;;;BA)(A;;GA;;;SY)S:(ML;;NW;;;ME)". This grants generic read/write access to Everyone (WD), retains full control for Administrators (BA) and LocalSystem (SY), and sets the Mandatory Label SACL to Medium Integrity (ME) with No-Write-Up (NW). - In crates/tsunagi/src/ipc/mod.rs, introduce default_control_socket_path() which points to %ProgramData%\tsunagi\agent.sock on Windows (and default per-user state directory on Unix). - In crates/tsunagi-cli/src/main.rs, support TSUNAGI_CONTROL_SOCKET environment variable across all commands, and use default_control_socket_path() on Windows when running against the default state directory. Custom state directories (--state-dir) or explicit sockets (--control-socket) continue to take precedence, allowing multi-daemon setups to remain strictly isolated. - In workspace Cargo.toml, set unsafe_code = "deny" so the workspace forbids unsafe code while permitting explicit, documented unsafe Win32 API calls in windows.rs. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets --jobs 2 -- --test-threads=2 passed (349 tests passed).	2026-10-01 00:13:44 +01:00
Aleksandr Bogomiakov	192ab25bbd	Support RUST_LOG, enable UPnP portmapper and add NAT traversal logging ... Previously, `tsunagi-cli` configured clap with a fixed default_value and `env = "TSUNAGI_LOG"`, which caused `RUST_LOG` to be completely ignored. In addition, `iroh` was built with `default-features = false` and lacked the `"portmapper"` feature, which caused it to compile a stub client and disable UPnP-IGD, PCP, and NAT-PMP port mapping. Furthermore, there was no visibility into STUN address discovery, UPnP port mapping status, or QUIC transmission path switching (hole punch vs relay). Key improvements: - Enable the `"portmapper"` feature on `iroh` in workspace Cargo.toml, pulling in `portmapper` and `igd-next` to actively request port mappings on local routers. - In `crates/tsunagi-cli/src/main.rs`, support `RUST_LOG` with fallback precedence (`--log` > `TSUNAGI_LOG` > `RUST_LOG` > default filter). When debug or trace filtering is active, automatically enable `.with_target(true)` so users can see which subsystem emitted the log (e.g., portmapper, iroh::magicsock, tsunagi::net). - In `crates/tsunagi/src/net.rs`, monitor `endpoint.watch_addr()` and `endpoint.home_relay_status()`. Emit `DEBUG` logs for local socket binding, discovered STUN reflexive/UPnP addresses, and relay connections. If no direct addresses are discovered after probe grace, emit a concise `WARN`. - In `crates/tsunagi/src/agent/session.rs`, monitor connection `path_events()` to log when transmission paths are opened, closed, or selected (switching between relay and direct hole-punched paths), with bounded task winding down on shutdown. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed (349 tests passed). - Live verification with `RUST_LOG=debug` confirmed SSDP broadcast to 239.255.255.250:1900, portmapper logs, STUN QAD discovery, and clean relay shutdown.	2026-09-30 23:08:23 +01:00
Aleksandr Bogomiakov	c0a76f1942	Enable all available protocols by default with tcp-tls priority ... By default, the agent now enables all available data plane protocols starting with `tcp-tls,wg-quic`, removing the need to manually pass `--protocol` to enable HTTPS-camouflage transport. The `--protocol` option remains available to explicitly restrict or select specific protocols (or reorder their priority). Furthermore, in `crates/tsunagi-tcp-tls`, if default port 443 is unavailable (e.g., due to permission constraints or address in use), the transport now attempts fallback port 8443, and if 8443 is also unavailable, gracefully falls back to an ephemeral port rather than failing agent startup. Key changes: - In `crates/tsunagi-cli/src/main.rs`, update `UpArgs::protocols` default_value to `"tcp-tls,wg-quic"`. - In `crates/tsunagi-cli/src/main.rs`, reorder `PROTOCOLS` registry with `tcp-tls` first, followed by `wg-quic`. - In `crates/tsunagi-tcp-tls/src/transport.rs`, add multi-tier fallback (443 -> 8443 -> ephemeral) for unconstrained port bindings. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed (349 tests passed). - cargo build --release passed.	2026-09-30 22:56:08 +01:00
Aleksandr Bogomiakov	510116afb9	Add automatic protocol fallback with backoff and silence DHT bootstrap error ... When multiple data plane protocols (such as tcp-tls and wg-quic) are configured, the agent previously attempted only the first mutually supported protocol in served order. If that protocol failed to connect or dropped (due to NAT, firewall, or handshake failure), ensure_links retried the exact same failed protocol on every tick without ever falling back to alternative supported protocols. Additionally, tcp-tls mistakenly included 127.0.0.1 in peer candidate lists, causing peers to connect to their own local listener and fail certificate verification (NotValidForName). Finally, BitTorrent DHT bootstrap failures in the third-party mainline crate were logged as noisy ERRORs despite overlay connectivity operating normally. Key improvements: - In crates/tsunagi/src/agent/network.rs, implement ProtocolDialState with exponential backoff (3s, 6s, 12s, 24s, 48s, capped at 60s). - In ensure_links, select the highest-priority mutually supported protocol that is not currently on backoff cooldown. If a protocol fails, immediately record the failure and fall back to alternative mutually supported protocols without waiting for the periodic ticker. - In crates/tsunagi-tcp-tls, remove localhost loopback from local_ip_candidates and capability announcements, and prevent open() from connecting to our own listening port. - In crates/tsunagi-cli/src/main.rs, set mainline=off in the default tracing filter so benign BitTorrent DHT routing table bootstrap errors do not alarm users. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed (349 tests passed). - cargo build --release passed.	2026-09-30 22:51:08 +01:00
Aleksandr Bogomiakov	e24548b3b0	Fix Windows address allocation check and add custom SNI for tcp-tls ... When running on Windows with Wintun, assigning an overlay IPv4 address via netsh triggers Duplicate Address Detection (DAD). During this tentative window, binding a UDP socket to the address returns WSAEADDRNOTAVAIL (os error 10049), causing the agent to prematurely log a false-positive PluginError ('allocated ... but the address is not on any interface'). Furthermore, Russian TSPU / DPI filters block unrecognized SNIs and non-standard ALPNs on TCP port 443 with TCP RST injection (os error 10054). The default 'tsunagi.local' SNI and 'tsunagi-tls/1' ALPN were trivially fingerprinted. Key improvements: - In crates/tsunagi/src/overlay/tun.rs, enhance address_is_local on Windows to inspect active OS interfaces via netdev::get_interfaces() if UDP bind fails. - In crates/tsunagi/src/agent/network.rs, introduce an asynchronous retry loop in publish_allocations on Windows (up to 1.5s in 150ms intervals) to gracefully allow DAD and IP helper updates to complete before reporting missing addresses. - In crates/tsunagi-tcp-tls, add support for custom SNI domain via protocol options (-o sni=<domain>), defaulting to 'cloudflare.com' instead of 'tsunagi.local'. - Switch TLS ALPN in tsunagi-tcp-tls from 'tsunagi-tls/1' to 'http/1.1' to camouflage handshake traffic as standard HTTPS web traffic. - Update tests to verify custom and default SNI behavior. Validation on Linux: - cargo fmt --all -- --check passed. - cargo clippy --locked --workspace --all-targets -- -D warnings passed. - cargo test --locked --workspace --all-targets passed (348 tests passed). - cargo build --release passed.	2026-09-30 20:38:16 +01:00