hickory_resolver's TokioResolver only consults /etc/resolv.conf and
queries upstream DNS servers — which means it can't see /etc/hosts,
mDNS (Avahi/Bonjour), NetBIOS, or anything else in the system's full
name-resolution stack. On a typical home LAN there's no DNS server
that knows about peer machine names, so users had to fall back to
typing IP addresses, which broke the moment they moved their setup
to a different network.
Swap to tokio::net::lookup_host, which calls getaddrinfo (or
GetAddrInfoEx on Windows). That walks /etc/nsswitch.conf on Linux
(picking up Avahi-resolved .local names, /etc/hosts, and DNS), uses
Bonjour for .local on macOS, and the full Windows resolver on
Windows. A Bonjour hostname like "JKMBP-M4-Max.local" now resolves
on every modern network without explicit configuration; the user
can carry their two machines between LANs and the connection still
finds them.
Drop the hickory-resolver dependency entirely — it's no longer
needed. ServiceError::Dns also goes away; lookup failures surface as
io::Error which is already covered by ServiceError::Io.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
*breaking change*
this changes the configuration syntax, allowing for an unlimited amount of configured clients.
Also a first step towards enabling a "save config" feature.
client configuration now applies immediately instead of after enabling / disabling clients.
Also fixes a potential feedback loop when changing settings.
