Comparing d68df35409..4bbf08ed66 - lan-mouse - TheLanc3: Gitea server

TheLanc3/lan-mouse

mirror of https://github.com/feschber/lan-mouse.git synced 2026-06-17 05:44:48 +03:00

Author	SHA1	Message	Date
Ferdinand Schober	4bbf08ed66	use proper css styling for the font colors	2026-06-14 22:34:42 +02:00
Jon Kinney	63864a7fc9	chore: cargo fmt for peer-version code	2026-06-14 18:10:22 +02:00
Jon Kinney	9fb07a119f	fix(version-exchange): also store peer commit on the listen side Previously the Hello handler in `ListenTask` echoed our local commit back but deliberately threw away the peer's, on the assumption that the outgoing connect-side path (`connect.rs:278-279` → `set_peer_commit`) would always populate the visible state for any bidirectionally-configured peer. That assumption breaks any time the outgoing TCP/DTLS direction is broken even though the inbound direction is fine — happened just now when the peer Mac's daemon stopped listening on 4242 (DHCP-renewed IP, daemon crashed, asymmetric NAT, …). Mac was still happily connecting in the other direction and sending events, including the initial Hello, but Linux silently displayed "peer version unknown" because the listen side dropped Mac's commit on the floor. Add a `PeerHello { addr, commit }` EmulationEvent variant fired from the listen-side Hello handler. The service maps `addr → ClientHandle` via `client_manager.get_client(addr)` and calls `set_peer_commit` + `broadcast_client` exactly like the connect path does. The connect path remains the primary source for symmetric setups; this is the defensive fallback so version visibility doesn't depend on outbound reachability. Skips silently when no outgoing client is configured for the peer's addr (incoming-only setup) — there's no UI row to update in that case anyway. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-14 18:10:22 +02:00
Jon Kinney	1c92d9c5c7	ui(client_row): sentence-case "Peer version" and "Ours" labels These are user-visible labels in the version-status subtitle, so sentence-case reads better than the lowercase first-pass. "matched" stays lowercase since it's a status descriptor, not a label. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-14 18:10:22 +02:00
Jon Kinney	3b7570c062	feat: peer version exchange with soft-warn UI indicator Adds a one-shot Hello message to the lan-mouse wire protocol so each peer can display the other end's build commit hash and warn on version mismatch. Soft-warn only — mismatched versions never refuse traffic. Wire change (lan-mouse-proto) * `ProtoEvent::Hello { commit: [u8; 8] }` carries the 8-byte ASCII short commit from shadow_rs's `SHORT_COMMIT`. Encoded/decoded alongside the existing event variants. * `EventType::Hello` is appended to the enum so existing IDs are untouched. Old peers receive the event, hit `InvalidEventId`, and silently skip it via the forward-compat handler in `connect.rs::receive_loop` — the connection is unaffected. Daemon * Connect side sends one Hello immediately after the DTLS handshake authenticates and before the ping_pong loop starts. Best-effort, fire-and-forget — `log::debug!` on send error. * Listen side mirrors the peer's Hello with its own (same shape as the existing Ping → Pong reply), so the peer's connect-side receive_loop populates `ClientState::peer_commit` for that handle. * The disconnect path clears `peer_commit` so a stale hash isn't shown after the connection drops. IPC * `ClientState::peer_commit: Option<[u8; 8]>`. `None` means the peer hasn't sent Hello yet — either fresh connection or older build that predates the event. GTK * `ClientObject` exposes `peer-commit` as an `Option<String>` property; `peer_commit_to_string` converts the wire `[u8; 8]` to the displayable hex. * `lan_mouse_gtk::run` now takes the local commit and stashes it in a `OnceLock` so per-row UI can compare against each peer's hash. * `ClientRow::refresh_version_status` re-renders the collapsed subtitle with Pango markup whenever the property changes: - matched → green "peer version: <hex> · matched" - mismatch → orange "peer version: <hex> · ours: <hex>" - unknown → orange "peer version: unknown · ours: <hex>" * Window invokes `refresh_version_status` from `update_client_state` after writing the new property, and `bind` calls it once on row construction so the initial subtitle isn't blank. Known limitation: state-change broadcasts from the network side (set_alive / set_active_addr / set_peer_commit) don't currently trigger a `FrontendEvent::State` directly; the UI picks up the latest values on the next user-driven broadcast. Same pre-existing behavior as the alive/active_addr fields. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-14 18:10:22 +02:00
Jon Kinney	59b6447745	fix(proto): tolerate undecodable peer datagrams instead of disconnecting The DTLS recv loops in src/listen.rs and src/connect.rs each read one full datagram per call. A failed `try_into::<ProtoEvent>()` means the datagram's leading EventType byte didn't match any known variant — a misalignment is impossible because DTLS is message-framed, not stream-framed. Previously, src/listen.rs would `break` out of the loop on parse failure (tearing down the connection) and src/connect.rs would silently swallow the error with no log. Both are wrong as forward-compat behavior: any future protocol addition (e.g. a new event variant) would force every existing peer to disconnect rather than gracefully ignoring the unknown event. Skip-and-continue on both sides, with a debug-level log so the behavior is observable. Pre-requisite for any future ProtoEvent variant to land without forcing a coordinated upgrade across every peer in a deployment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-14 18:00:14 +02:00

Diff Content Not Available