[LEDE-DEV] mdnsd ignoring questions

[Cristian Morales Vega]

On 14 December 2016 at 17:01, John Crispin <john at phrozen.org> wrote:
> On 14/12/2016 17:35, Cristian Morales Vega wrote:
>> I have found a problem with mdnsd, but since I'm no expert in the
>> protocol and would prefer to stay that way, could somebody comment on
>> these?
>>
>> The problem is with service_reply_single()
>> (https://git.lede-project.org/?p=project/mdnsd.git;a=blob;f=service.c;h=fe6e5a91d31bd3475e47b3775db3e3474b848de6;hb=HEAD#l153).
>>
>> The call to service_timeout() resets the timeout counter, but if the
>> later strcmp(match, s->service) check fails, the service is not
>> actually announced. Since service_reply() calls service_reply_single()
>> for every single registered service, it means that every time an
>> Android phone in the networks looks for a Chromecast it resets the
>> timeout counter of the _ssh counter. And when later somebody asks for
>> the _ssh service, mdnsd will fail to reply.
>>
>> I would be tempted to just get rid of the service_timeout() call. Why
>> does it exist? There would really be a problem if mdnsd would reply to
>> every single request, even when it has already replied to it half a
>> second ago?
>
> yes, this is specifically requested by the RFC. there is an example how
> 32 device will hog 100mbit if the resend threshold is not properly
> implemented. i'll need to have a closer look at this in the next couple
> of days. busy with other stuff today. i have put it onto my todo list.

Thanks.
Happy to wait a couple of days. But I have spend the last hour getting
a bit more familiar with mDNS and I didn't find any reference to this
resend threshold in the RFC. I would expect it to be in section 7
(Traffic Reduction), but it's not there. Do you happen to remember
where it is? (don't look for it if you don't)
I'm surprised the standard says this. Letting a new host in the
network miss information about a service sounds horrible.

>> I could also change the order of the strcmp(match, s->service) and
>> service_timeout() checks, but notice that when a device looks for a
>> service via both IPv4 and IPv6 changing the order of the checks would
>> still make it, for example, get a reply via IPv6 and not via IPv4
>> (which I guess can be a good thing since it's just a duplicate?).

Actually this would be a problem since an IPv4-only host could ask for
it immediately after an IPv6-only host. Both need to be replied.