Message ID | 20170213154235.23168-1-zajec5@gmail.com |
---|---|
State | Accepted |
Delegated to: | Rafał Miłecki |
Headers | show |
On 13 February 2017 at 15:42, Rafał Miłecki <zajec5@gmail.com> wrote: > From: Rafał Miłecki <rafal@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@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.
On 04/21/2017 03:31 PM, Cristian Morales Vega wrote: > On 13 February 2017 at 15:42, Rafał Miłecki <zajec5@gmail.com> wrote: >> From: Rafał Miłecki <rafal@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@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.
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@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@gmail.com> wrote: >>> >>> From: Rafał Miłecki <rafal@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@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. >
> On 10 May 2017 at 13:14, Rafał Miłecki <zajec5@gmail.com> wrote: >> 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. 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... and I managed to top-post before!) With those patches it works for me.
On 10 May 2017 at 14:20, Cristian Morales Vega <cristian@samknows.com> wrote: >> On 10 May 2017 at 13:14, Rafał Miłecki <zajec5@gmail.com> wrote: >>> 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. > > 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... and I managed to top-post before!) > > With those patches it works for me. Tip of the day: opening UDP port 5353 may help. Sorry for that mistake. I can see this working now.
On 10 May 2017 at 13:44, Rafał Miłecki <zajec5@gmail.com> wrote: > On 10 May 2017 at 14:20, Cristian Morales Vega <cristian@samknows.com> wrote: >>> On 10 May 2017 at 13:14, Rafał Miłecki <zajec5@gmail.com> wrote: >>>> 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. >> >> 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... and I managed to top-post before!) >> >> With those patches it works for me. > > Tip of the day: opening UDP port 5353 may help. > > Sorry for that mistake. I can see this working now. This definitively still fails for me with an iPad as per http://lists.infradead.org/pipermail/lede-dev/2017-April/007188.html This is what I see 09:18:53.732502 IP SamKnowsiPadAir.sk.lan.mdns > 224.0.0.251.mdns: 0 [2q] [1au] PTR (QU)? _skhttp._tcp.local. PTR (QU)? _skjitter._tcp.local. (81) 09:18:53.732776 IP 10.0.2.186.mdns > SamKnowsiPadAir.sk.lan.mdns: 0*- [0q] 1/0/0 PTR SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. (86) 09:18:53.732859 IP 10.0.2.186.mdns > SamKnowsiPadAir.sk.lan.mdns: 0*- [0q] 2/0/0 SRV SKWB8-d8:37:be:f8:21:25.local.:6500 5971 19287, TXT "daemon=skhttp_server" (178) 09:18:53.732930 IP 10.0.2.186.mdns > SamKnowsiPadAir.sk.lan.mdns: 0*- [0q] 1/0/0 PTR SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. (90) 09:18:53.732981 IP 10.0.2.186.mdns > SamKnowsiPadAir.sk.lan.mdns: 0*- [0q] 2/0/0 SRV SKWB8-d8:37:be:f8:21:25.local.:6003 5971 19287, TXT "daemon=hjitter_server" (183) 09:18:53.734287 IP6 fe80::8f2:45ac:2ef8:a5da.mdns > ff02::fb.mdns: 0 [2q] [1au] PTR (QU)? _skhttp._tcp.local. PTR (QU)? _skjitter._tcp.local. (81) 09:18:53.866207 IP SamKnowsiPadAir.sk.lan.mdns > 224.0.0.251.mdns: 0 [4q] [1au] SRV (QU)? SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. TXT (QU)? SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. SRV (QU)? SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. TXT (QU)? SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. (141) 09:18:53.866919 IP6 fe80::8f2:45ac:2ef8:a5da.mdns > ff02::fb.mdns: 0 [4q] [1au] SRV (QU)? SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. TXT (QU)? SKWB8-d8:37:be:f8:21:25._skhttp._tcp.local. SRV (QU)? SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. TXT (QU)? SKWB8-d8:37:be:f8:21:25._skjitter._tcp.local. (141) The iPad seems to expect the PTR and SRV records in the same packet (12.1 from RFC6763 says they "should", not "must") and since the SRV is not there it ends up asking for it... and not noticing we have sent it before in a different packet. So we need to handle SRV questions (http://lists.infradead.org/pipermail/lede-dev/2017-April/007177.html). But that's not enough because there is a timeout (http://lists.infradead.org/pipermail/lede-dev/2017-April/007179.html), which I am still not sure should be there.
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: