New issue
Advanced search Search tips

Issue 20 link

Starred by 1 user

Issue metadata

Status: Fixed
Closed: Jan 9

Sign in to add a comment

Resolve how to handle multihomed mDNS situations

Project Member Reported by, Dec 12

Issue description

There is currently a problem in both how we advertise addresses on multihomed systems and how we handle collecting responses on multihomed systems.

The former is a simply an attempt to violate the mDNS spec (section 6.2) [1] by advertise all addresses for our hostname on all interfaces.  This is a bug in MdnsResponderAdapterImpl::AdvertiseInterfaces, where we claim each address is a unique record for the hostname, but broadcast to all interfaces.  The result is that mDNSResponder only picks one as a result of the probing step (section 8.1 [1]).  Instead, we should only advertise the addresses for an interface on that interface.

The latter is more complicated, so we need to evaluate how much complexity we want to accept to support this edge case.  Consider a machine with two interfaces: eth0 and eth1.  If some service is advertised on eth1 with hostname alpha.local, but there is an unrelated alpha.local accessible on eth0, this is a conflict (but not a conflict in the normal mDNS sense, as we are assuming eth0 and eth1 are not sharing multicast traffic).  Before considering solutions, though, we should also consider the case that eth0 and eth1 do in fact attach to the same LAN so records would be valid on both and are seen by both.

The first necessary step is to restrict follow-up service discovery queries (e.g. SRV/TXT queries from a PTR response) to the interface on which the first response was received.  This would prevent us from asking for alpha.local on eth0 in the first place.

The remaining issue is whether we want to actually track services per-interface, or just consider all name conflicts across interfaces to mean that the interfaces are just on the same network.  The former dramatically complicates the state we need to track when going from mDNS records up to ScreenInfo, because we would then need to de-duplicate ScreenInfos that are actually the same and just seen on different interfaces that are part of the same network (i.e. the latter network case above).  The positive, though, is that this wouldn't make the single interface case anymore complicated because there would be no interfaces to de-dup against.  The latter is a much smaller code change, and would only be incorrect for what is likely a very very small fraction of use cases.

Project Member

Comment 1 by, Dec 12

Status: Started (was: Assigned)
Project Member

Comment 2 by, Jan 9

Status: Fixed (was: Started)
A compromise for this was landed as f970d6177d49c845fb2d3489384c82bcb7491fc4.

The compromise is essentially to only track a given service on the first interface that we receive its PTR response.

Sign in to add a comment