[LEDE-DEV] [PATCH mdns] Fix sending replies to PTR questions

Rafał Miłecki zajec5 at gmail.com
Wed May 10 05:14:08 PDT 2017


On 04/21/2017 03:31 PM, Cristian Morales Vega wrote:
> On 13 February 2017 at 15:42, Rafał Miłecki <zajec5 at gmail.com> wrote:
>> From: Rafał Miłecki <rafal at milecki.pl>
>>
>> When we receive PTR question it includes hostname (instance), e.g.:
>> mdnsd: parse_question (391): Q -> PTR lede._http._tcp.local
>>
>> First of all we should check if it matches hostname we use before trying
>> to reply. Secondly service_reply expects service with domain appended
>> (without hostname/instance) so we need to strip received string out of
>> hostname before passing it.
>>
>> Signed-off-by: Rafał Miłecki <rafal at milecki.pl>
>> ---
>>  dns.c | 14 ++++++++++++--
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/dns.c b/dns.c
>> index 91434f2..dac6f2c 100644
>> --- a/dns.c
>> +++ b/dns.c
>> @@ -367,9 +367,19 @@ parse_question(struct interface *iface, char *name, struct dns_question *q)
>>                 break;
>>
>>         case TYPE_PTR:
>> -               if (!strcmp(name, sdudp))
>> +               if (!strcmp(name, sdudp)) {
>>                         service_announce_services(iface, announce_ttl);
>> -               service_reply(iface, name, announce_ttl);
>> +               } else {
>> +                       /* First dot separates instance name from the rest */
>> +                       char *dot = strchr(name, '.');
>> +                       /* Length of queried instance */
>> +                       size_t len = dot ? dot - name : 0;
>> +
>> +                       /* Make sure it's query for the instance name we use */
>> +                       if (len && len == strlen(mdns_hostname) &&
>> +                           !strncmp(name, mdns_hostname, len))
>> +                               service_reply(iface, dot + 1, announce_ttl);
>> +               }
>>                 break;
>>
>>         case TYPE_AAAA:
>
>
> Isn't this failing to take into account the case when there is no hostname?
>
> With 480d7bc74eba20c03875aa06c1c25dbdb98e0b12 running on SKWB8:
>
> $ sudo systemctl restart avahi-daemon
> $ avahi-browse -ck '_ssh._tcp'
> $ avahi-browse -tk '_ssh._tcp'
> + enp0s25 IPv6 linux-vf7n                                    _ssh._tcp
>            local
> + enp0s25 IPv4 linux-vf7n                                    _ssh._tcp
>            local
> $ avahi-browse -atk
> + enp0s25 IPv6 SKWB8
> _skhttp._tcp         local
> + enp0s25 IPv6 SKWB8
> _skjitter._tcp       local
> + enp0s25 IPv6 SKWB8                                         _ssh._tcp
>            local
> + enp0s25 IPv6 linux-vf7n                                    _ssh._tcp
>            local
> + enp0s25 IPv4 linux-vf7n                                    _ssh._tcp
>            local
> + enp0s25 IPv4 SKWB8
> _skhttp._tcp         local
> + enp0s25 IPv4 SKWB8
> _skjitter._tcp       local
> + enp0s25 IPv4 SKWB8                                         _ssh._tcp
>            local
> + enp0s25 IPv6 linux-vf7n
> _sftp-ssh._tcp       local
> + enp0s25 IPv6 linux-vf7n [14:da:e9:f7:1b:95]
> _workstation._tcp    local
> + enp0s25 IPv4 linux-vf7n
> _sftp-ssh._tcp       local
> + enp0s25 IPv4 linux-vf7n [14:da:e9:f7:1b:95]
> _workstation._tcp    local
> $ avahi-browse -ck '_ssh._tcp'
> + enp0s25 IPv6 SKWB8                                         _ssh._tcp
>            local
> + enp0s25 IPv6 linux-vf7n                                    _ssh._tcp
>            local
> + enp0s25 IPv4 SKWB8                                         _ssh._tcp
>            local
> + enp0s25 IPv4 linux-vf7n                                    _ssh._tcp
>            local
> $ avahi-browse -tk '_ssh._tcp'
> + enp0s25 IPv6 SKWB8                                         _ssh._tcp
>            local
> + enp0s25 IPv6 linux-vf7n                                    _ssh._tcp
>            local
> + enp0s25 IPv4 SKWB8                                         _ssh._tcp
>            local
> + enp0s25 IPv4 linux-vf7n                                    _ssh._tcp
>            local
> $
>
> When running with -d umdns says things like
>
> mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
> mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
> mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
> mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
> mdnsd: parse_question (366): Q -> PTR _services._dns-sd._udp.local
> mdnsd: dns_send_answer (178): A <- A SKWB8.local
> mdnsd: dns_send_answer (178): A <- AAAA SKWB8.local
> mdnsd: dns_send_answer (178): A <- PTR _services._dns-sd._udp.local
> mdnsd: dns_send_answer (178): A <- PTR _skhttp._tcp.local
> mdnsd: dns_send_answer (178): A <- SRV SKWB8._skhttp._tcp.local
> mdnsd: dns_send_answer (178): A <- TXT SKWB8._skhttp._tcp.local
> mdnsd: dns_send_answer (178): A <- PTR _services._dns-sd._udp.local
> mdnsd: dns_send_answer (178): A <- PTR _skjitter._tcp.local
> mdnsd: dns_send_answer (178): A <- SRV SKWB8._skjitter._tcp.local
> mdnsd: dns_send_answer (178): A <- TXT SKWB8._skjitter._tcp.local
> mdnsd: dns_send_answer (178): A <- PTR _services._dns-sd._udp.local
> mdnsd: dns_send_answer (178): A <- PTR _ssh._tcp.local
> mdnsd: dns_send_answer (178): A <- SRV SKWB8._ssh._tcp.local
> mdnsd: dns_send_answer (178): A <- TXT SKWB8._ssh._tcp.local
>
> So it's seems it's not answering to the _ssh._tcp queries.

After reading your comment & analyzing the code: yes. I expect this to break
support for queries you mentioned.

My problem is that even without this commit or my local fix avahi-browse
still doesn't detect services announced by umdns. I can see answers being
sent so I assume there is something wrong with them.

I've to debug it further.




More information about the Lede-dev mailing list