On 14 December 2016 at 17:01, John Crispin <j...@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. _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev