discovery: allow limiting the advertised ip addresses - #1425
Open
Hayao0819 wants to merge 1 commit into
Open
Conversation
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
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.
The mDNS responder advertises an A record for every interface, because spotifyd never fills in the
zeroconf_iplist that librespot's builder has been offering all along:Builder::zeroconf_ip.On a box with docker, tailscale and a dozen emulator taps, clients pick whichever record they like. Mine kept landing on a 192.168.94.x tap address that nothing on the LAN can reach.
--zeroconf-ip 10.0.0.5/zeroconf_ip = ["10.0.0.5"]limits what goes out. Plumbed the same way aszeroconf_port.#990 asked for this back in 2021 and stalled on the conclusion that librespot was in the way, "Zeroconf discovery is hardcoded to bind to
0.0.0.0", with a later comment: "I would like to use a specific bind ip. With multiple IP addresses on one machine, this is a critical need." That was accurate then. The builder method exists now and nothing on our side was calling it. #1285 is the adjacent report, where a second IPv4 on one interface breaks discovery and removing it brings the device back.This closes neither of them. libmdns applies the list when it builds answer records and nowhere else:
fsm.rs#L244. The socket still bindsANY_ADDRand still joins the multicast group on every non-loopback interface:address_family.rs#L26. The discovery TCP listener is untouched. The bind half of #990 and the failure in #1285 both stay open.