Issues with Probing and Announcing, or conflict detection

[fzs]

While working on IPv6 support I stumbled over conflicts being detected for records where none were detected before. Which made me look a bit further into the code for conflicts and probing and announcing, and I think mdnsd has multiple issues there.

Well, I haven't really looked into it very thoroughly, yet. My gut feeling is that it is utterly broken and could need a rewrite. But who has time for that, right? =) But maybe it can be fixed piece by piece.

I am opening this discussion to gather the issues I encounter and hopefully discuss them with whoever is more knowledgeable to see if and how to fix them. I'll add multiple sub-posts for what I find so they can be discussed separately but are gathered here.

@troglobit, let me know should you have a preference on whether GH issues should be created for the findings or rather not. I have started with a first one, which should be an easy fix.

[fzs]

For starters, there seems to be a copy-paste error in the _a_match function comparing record identity for A and AAAA records. In their case the function will always return 1. I created #71 for that.

[fzs]

This has been fixed in PR #73

[fzs]

I mentioned the problems started when adding IPv6. The way it is implemented, each interface gets an IPv4 and a separate IPv6 socket. Over both probing and announcing is run. This actually works fine for the normal case, which is why this is a point for discussion and not immediately an issue.

So when does this run into problems? I develop and test on a Linux VM with more than one interface. As alluded to in PR #69, this can result in interesting behaviour in certain cases. One such case is where there are multiple interfaces and mdnsd is not started as root, i.e. with root privileges. Because binding a socket to an interface with SO_BINDTODEVICE requires root privileges. In that case, IPv6 multicast packets sent on interface A will be received on interface B, even though the socket used for interface B did not join the multicast group on interface A.

This means that the same record will now be received on interface B`s socket but coming from the IPv6 address of interface A. Which is detected as a conflict. This was not a problem for IPv4 because there the behaviour is different.

The question is, is mdnsd only to be run as root, in which case the problem does not arise? In that case it should probably be mentioned in the documentation somehow. Or should this be fixed? Fixing it would mean that the detection if the packet came from us needs to be changed, taking all active interfaces into account. Which might get difficult on a library level, because there the mdnsd instances are independent and don't know about each other. Given that right now no interface-specific services are supported, it would be in line with the mdnsd serving all services on all interfaces.
Maybe there is also a way to fix the behaviour on Linux, but I haven't found a way.

[troglobit]

Hi, sorry for the late reply.

It would be great if it could run as non-root, but with the constraints of sockets wrt. multicast being what they are, I'm fine with requiring root or the correct capabilities. We could always add support for dropping privileges later.

So, since we now run as root we need to consider that mdsnd preferably should run on any UNIX (or at least FreeBSD). I believe SO_BINDTODEVICE is Linux-only, but they have something else I believe in the *BSD. This is a secondary target, so "make it work" is priority n:o one.

Re: rhe issue with packets sent on one socket being seen on other(s), have you seen the IP_MULTICAST_LOOP socket option. I don't remember right now but I believe there's a similar one for IPv6 as well. I do remember, however, having dived into these exact topics while working on both SMCRoute and pim6sd (others exist too, like mrouted, but these are representative). So I invite you to have a look at them.

[fzs]

I have seen IP_MULTICAST_LOOP and I was wary why it was enabled as it seems like a bad idea for the exact reason that a mDNS responder doesn't need to see its own packets again. It is being set for IPv6 the same way it is set for IPv4. The argument for it being enabled appears to be so that mquery can be run from the same computer/device. I check the avahi code for reference from time to time and they also have it enabled.

[fzs]

Maybe checking for a conflict with records from the same machine but a different interface doesn't have to happen on the library level. We could also extend the conflict handling on the application level to check if the incoming conflicting record did actually originate from our application. This would mean that the conflict callback would have to be extended so that the packet source can be passed to the application.

Preferably, I would find a fix so that IPv4 and IPv6 behave the same way, but honestly I cannot invest that much time right now. So this could be a change that keeps it working without root privileges. It is a breaking change, though, since the interface to the application changes in an incompatible way.

[troglobit]

Yeah that sounds like a good approach (conflict handling on app level).

Well, don't worry too much about incompatible changes. If you keep this up, the next release will be v1.0 and we can bump ABIs etc. Go go go! :)