fix(relay): warn at startup when the IPv6 loopback port is squatted#2559
Open
luthen-seas wants to merge 1 commit into
Open
fix(relay): warn at startup when the IPv6 loopback port is squatted#2559luthen-seas wants to merge 1 commit into
luthen-seas wants to merge 1 commit into
Conversation
The default bind is IPv4-only 0.0.0.0:3000, and localhost resolves IPv6-first on macOS - so an unrelated process on [::1]:3000 (commonly a Vite dev server) silently intercepts local clients. Dev servers answer GETs with 200 and writes with 404, which presents as a relay bug during first-launch onboarding. Adds a warn-only probe after binding: when bound IPv4-only and something is listening on the IPv6 loopback at the same port, log a warning with the BUZZ_BIND_ADDR=[::]:<port> remediation. No binding behavior changes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a warn-only startup probe to
buzz-relay: after binding, if the relay is bound IPv4-only (the0.0.0.0:3000default) and another process is listening on[::1]:<port>, log a warning naming the fix (BUZZ_BIND_ADDR=[::]:<port>or freeing the port). No binding behavior changes.Why
On macOS,
localhostresolves to::1first. With the IPv4-only default bind, any unrelated listener on[::1]:3000(a Vite dev server is the classic case, since 3000 is a popular default) silently intercepts local desktop traffic. Dev servers answer GETs with 200 (SPA fallback) and writes with 404 — during first-launch onboarding this presents asrelay returned 404 Not Foundon profile save while the relay logs show zero inbound traffic. We lost a debugging session to exactly this. The desktop's HTML-interception detection (classify_intercepted_response) softens the symptom client-side, and #1245 fixed a sibling v4/v6 localhost issue for media proxy URLs, but nothing warns at the source.Changing the default bind to
[::]:3000would fix it structurally but changes dual-stack behavior across platforms/containers — deliberately not done here; happy to discuss that as a follow-up if maintainers prefer it.How
ipv6_loopback_squatter(port)— a 250msTcpStream::connect_timeoutprobe against[::1]:<port>; runs once at startup, only when the bind address is IPv4 (an[::]bind would connect to itself).buzz-relay TCP listeningline.unwrap()/expect(); probe failure can never affect binding.Testing
ipv6_loopback_squatter_detects_listener(binds an ephemeral[::1]listener, asserts detection, then asserts clean after drop; skips silently on IPv6-less environments).cargo fmtclean;cargo clippy -p buzz-relay --all-targetsclean;cargo test -p buzz-relay ipv6_loopback_squatterpasses.[::1]:3000(e.g. a Vite dev server), start the relay with defaults, observe the warning.🤖 Generated with Claude Code