Skip to content

fix(dns): retry hostname lookup when entering a client with no IPs - #520

Open
fullstacksushil wants to merge 1 commit into
feschber:mainfrom
fullstacksushil:fix/retry-failed-dns-lookup
Open

fullstacksushil wants to merge 1 commit into
feschber:mainfrom
fullstacksushil:fix/retry-failed-dns-lookup

Conversation

@fullstacksushil

Copy link
Copy Markdown

Fixes #519.

A client's hostname is only resolved on activation, on hostname change, or when the user clicks the DNS button. If that first lookup fails, for example because the daemon starts at login before the network or mDNS is up, the client keeps an empty IP list and every connect attempt fails until lan-mouse is restarted.

This re-resolves the hostname on ClientEntered when the client has no IPs and no lookup is already running, so crossing the screen edge after the network comes up is enough to recover.

cargo clippy --workspace --all-targets --all-features and cargo test --workspace pass. I hit this on Linux (Hyprland) with a Mac peer and haven't tested the patched build end to end yet.

🤖 Generated with Claude Code

A hostname is only resolved on activation, hostname change or a manual
ResolveDns request. If that lookup fails (e.g. the daemon starts at login
before the network or mDNS is up), the client keeps an empty IP list and
every connect attempt fails until lan-mouse is restarted.

Re-resolve on ClientEntered when the client has no IPs and no lookup is
in flight.

Fixes feschber#519

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Daemon never retries a failed hostname lookup, client stays unreachable

1 participant