[LEDE-DEV] [PATCH mdns] Fix sending replies to PTR questions
Cristian Morales Vega
cristian at samknows.com
Wed May 10 05:18:25 PDT 2017
See http://lists.infradead.org/pipermail/lede-dev/2017-April/007177.html
and http://lists.infradead.org/pipermail/lede-dev/2017-April/007188.html
(yes, I have to improve my email workflow)
With those patches it works for me.
On 10 May 2017 at 13:14, Rafał Miłecki <zajec5 at gmail.com> wrote:
> 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.
>
--
Cristian Morales Vega
Email cristian at samknows.com
Office +44 (0) 20 3111 4330
Web: www.samknows.com
This email is sent for and on behalf of SamKnows Limited.
This email and any attachments are confidential, legally privileged
and protected by copyright. If you are not the intended recipient
dissemination or copying of this email is prohibited. If you have
received this in error, please notify the sender by replying by email
and then delete the email completely from your system.
SamKnows Limited, Registered Number: 06510477, Registered Office: Hill
House, 1 Little New Street, London, EC4A 3TR. Registered in England
and Wales. Trade Mark 2507103
More information about the Lede-dev
mailing list