feat: discover Lan Mouse devices on the local network (mDNS + broadcast)

[ekremyk2]

What this does

Lan Mouse devices on the same network find each other, so they can be added without typing a hostname or IP address.

• Each instance advertises itself as a _lan-mouse._udp DNS-SD service over mDNS (the pure-Rust mdns-sd crate, so no Avahi/Bonjour dependency). The TXT record carries the device name, its certificate fingerprint and its OS.
• Each instance also broadcasts a small JSON beacon on UDP port 4241 every 5 seconds and answers new devices directly. Many home routers drop multicast between Wi-Fi and Ethernet. That's how I ran into this: a Windows PC on Ethernet and a MacBook on Wi-Fi never saw each other's mDNS announcements. Reports from both methods are merged per device, and beacons expire when a device goes away.
• CLI:
  • lan-mouse cli discover lists nearby devices with their addresses and fingerprints.
  • lan-mouse cli add-discovered <name> <left|right|top|bottom> adds (or reuses) a client for a device and activates it.
  • lan-mouse cli authorize-discovered <name> lets that device control this one.
• A client that matches a discovered device, by hostname or by one of its configured or resolved addresses, gets the device's announced addresses. The client keeps working when DHCP hands out a new IP.
• discovery = false in the config turns it off. It needs UDP 5353 (mDNS) and 4241 (broadcast); the firewalld service file is updated.

It also includes a small fix the new commands rely on: every CLI command now waits until the service has handled it (a Ping/Pong round trip). On Windows, the CLI exiting right after writing a request could reset the IPC connection, and the service dropped requests it had not read yet. I'm happy to split this into its own PR if you prefer.

Related

• Feature: resolution of mDNS host name (.local) #261: this doesn't resolve arbitrary .local names, but devices running Lan Mouse no longer need a hostname at all.
• It's different from the closed feat(discovery): mDNS-SD primary-IP hints for service-order-aware dialing #433, which used mDNS to pick which interface to dial. This is about finding and adding devices.

Security note

authorize-discovered trusts the fingerprint a device announces on the network, so it is only meant for trusted networks. discover lists the fingerprints for comparison, and the README says so.

Not included

There is no GUI for discovered devices yet; it's CLI only, like the README says. If you like the approach, I can add a "nearby devices" list to the GTK window in a follow-up.

Testing

• Windows 11 on Ethernet and macOS on Wi-Fi, behind a router that filters multicast between the two: they found each other through the broadcast beacons, then were added and connected in both directions.
• Unit tests cover hostname matching, address filtering, the beacon round trip and merging mDNS with beacon reports. Two #[ignore]d tests discover a peer over real sockets.
• Linux was built and tested by CI only. All build, check and test jobs pass on Linux, Windows and macOS (Apple silicon and Intel).
• The only red job is clippy on Linux, and it comes from code this PR doesn't touch: Rust 1.99's new double_must_use lint flags the #[async_trait] traits in input-emulation, so main fails it too now. chore(deps): update async-trait to 0.1.92 (fixes clippy with Rust 1.99) #531 fixes that by updating async-trait to 0.1.92.

AI disclosure

This was written with the help of AI (Claude by Anthropic) and tested on my own Windows PC and Mac.