search

vincentbernat / dashkiosk

Managing dashboards on various displays (especially those running on Android)
Other
364 stars 62 forks source link

nodecastor discover hangs #20

Open graham-m-dunn opened 9 years ago

graham-m-dunn commented 9 years ago

v2.5.0, running ./dist/node_modules/nodecastor/bin/chromecast discover returns

** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=node&f=DNSServiceRegister>

and waits there forever. Any ideas on where to start looking for a solution? This used to work under v2.3.5, I've copied over the db from there to 2.4.0, and now into 2.5.0.

vincentbernat commented 9 years ago

❦ 23 mars 2015 09:54 -0700, Graham Dunn notifications@github.com :

v2.5.0, running ./dist/node_modules/nodecastor/bin/chromecast discover returns

\ WARNING * The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi. * WARNING * Please fix your application to use the native API of Avahi! * WARNING *\ For more information see http://0pointer.de/avahi-compat?s=libdns_sd&e=node&f=DNSServiceRegister

and waits there forever. Any ideas on where to start looking for a solution? This used to work under v2.3.5, I've copied over the db from there to 2.4.0, and now into 2.5.0.

Does the Chromecast appear when you use avahi-browse -a?

Make it clear before you make it faster.

graham-m-dunn commented 9 years ago

I get replies from the local interfaces (eth0 is disabled), but that's all:

avahi-browse -a

On Mon, Mar 23, 2015 at 3:34 PM, Vincent Bernat notifications@github.com wrote:

❦ 23 mars 2015 09:54 -0700, Graham Dunn notifications@github.com :

v2.5.0, running ./dist/node_modules/nodecastor/bin/chromecast discover returns

\ WARNING * The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi. * WARNING * Please fix your application to use the native API of Avahi! * WARNING *\ For more information see < http://0pointer.de/avahi-compat?s=libdns_sd&e=node&f=DNSServiceRegister>

and waits there forever. Any ideas on where to start looking for a solution? This used to work under v2.3.5, I've copied over the db from there to 2.4.0, and now into 2.5.0.

Does the Chromecast appear when you use avahi-browse -a?

Make it clear before you make it faster.

  • The Elements of Programming Style (Kernighan & Plauger)

— Reply to this email directly or view it on GitHub https://github.com/vincentbernat/dashkiosk/issues/20#issuecomment-85160206 .

(kik: graham_m_dunn || 519-572-9812)

vincentbernat commented 9 years ago

❦ 23 mars 2015 12:36 -0700, Graham Dunn notifications@github.com :

I get replies from the local interfaces (eth0 is disabled), but that's all:

avahi-browse -a

  • eth1 IPv4 ykf-dash-1 [00:00:00:00:00:00] Workstation local
  • eth1 IPv4 ykf-dash-1 SSH Remote Terminal local

So, you don't see the Chromecast? Do you have any firewall rules?

Program defensively.

graham-m-dunn commented 9 years ago

iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Nope.

There are a ton of wireless clients and 10+ chromecasts on this network, I would expect to see a bunch of traffic.

On Mon, Mar 23, 2015 at 4:20 PM, Vincent Bernat notifications@github.com wrote:

❦ 23 mars 2015 12:36 -0700, Graham Dunn notifications@github.com :

I get replies from the local interfaces (eth0 is disabled), but that's all:

avahi-browse -a

  • eth1 IPv4 ykf-dash-1 [00:00:00:00:00:00] Workstation local
  • eth1 IPv4 ykf-dash-1 SSH Remote Terminal local

So, you don't see the Chromecast? Do you have any firewall rules?

Program defensively.

  • The Elements of Programming Style (Kernighan & Plauger)

— Reply to this email directly or view it on GitHub https://github.com/vincentbernat/dashkiosk/issues/20#issuecomment-85176390 .

(kik: graham_m_dunn || 519-572-9812)

vincentbernat commented 9 years ago

❦ 23 mars 2015 13:56 -0700, Graham Dunn notifications@github.com :

iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Nope.

There are a ton of wireless clients and 10+ chromecasts on this network, I would expect to see a bunch of traffic.

Maybe there is some logs about avahi in /var/log/messages that would explain that? Or you could try to restart avahi-daemon, maybe it is stuck in some bad state.

You could also check with tcpdump that you are receiving mDNS (tcpdump

-pni eth1 port 5353 and not src host yourip).

What no spouse of a writer can ever understand is that a writer is working when he's staring out the window.

graham-m-dunn commented 9 years ago

tcpdump -pni eth0 port 5353 and not src host 10.10.20.13

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

12:43:23.357598 IP 10.10.20.92.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _googlecast._tcp.local. (40)

12:43:23.420919 IP 10.10.20.17.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _googlecast._tcp.local. (40)

12:43:23.945507 IP 10.10.20.152.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _googlecast._tcp.local. (40)

12:43:24.058758 IP6 fe80::1ab4:30ff:fe16:71e.mdns > ff02::fb.mdns: 0*- [0q] 2/0/0 (Cache flush) PTR 02AA01AC4614020D.local., (Cache flush) A 10.10.20.223 (89)

12:43:24.420936 IP 10.10.20.17.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _googlecast._tcp.local. (40)

12:43:24.421575 IP 10.10.20.92.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _googlecast._tcp.local. (40)

12:43:25.422748 IP 10.10.20.17.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _googlecast._tcp.local. (40)

12:43:25.433694 IP 10.10.20.92.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _googlecast._tcp.local. (40)

12:43:27.353023 IP 10.10.20.223.mdns > 224.0.0.251.mdns: 0 [3q] [5n] ANY (QM)? e.1.7.0.6.1.e.f.f.f.0.3.4.b.a.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? 02AA01AC4614020D.local. ANY (QM)? 223.20.10.10.in-addr.arpa. (242)

12:43:27.355430 IP6 fe80::1ab4:30ff:fe16:71e.mdns > ff02::fb.mdns: 0 [2q] [2n] ANY (QM)? 223.20.10.10.in-addr.arpa. ANY (QM)? 02AA01AC4614020D.local. (101)

12:43:27.389281 IP6 fe80::1ab4:30ff:fe16:71e.mdns > ff02::fb.mdns: 0*- [0q] 2/0/0 (Cache flush) HINFO, (Cache flush) AAAA fe80::1ab4:30ff:fe16:71e (87)

12:43:27.608497 IP 10.10.20.223.mdns > 224.0.0.251.mdns: 0 [3q] [5n] ANY (QM)? e.1.7.0.6.1.e.f.f.f.0.3.4.b.a.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? 02AA01AC4614020D.local. ANY (QM)? 223.20.10.10.in-addr.arpa. (242)

12:43:27.608955 IP6 fe80::1ab4:30ff:fe16:71e.mdns > ff02::fb.mdns: 0 [2q] [2n] ANY (QM)? 223.20.10.10.in-addr.arpa. ANY (QM)? 02AA01AC4614020D.local. (101)

12:43:27.687599 IP 10.10.20.152.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _googlecast._tcp.local. (40)

12:43:27.852727 IP 10.10.20.223.mdns > 224.0.0.251.mdns: 0 [3q] [5n] ANY (QM)? e.1.7.0.6.1.e.f.f.f.0.3.4.b.a.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? 02AA01AC4614020D.local. ANY (QM)? 223.20.10.10.in-addr.arpa. (242)

12:43:27.853106 IP6 fe80::1ab4:30ff:fe16:71e.mdns > ff02::fb.mdns: 0 [2q] [2n] ANY (QM)? 223.20.10.10.in-addr.arpa. ANY (QM)? 02AA01AC4614020D.local. (101)

12:43:28.058038 IP 10.10.20.223.mdns > 224.0.0.251.mdns: 0*- [0q] 5/0/0 (Cache flush) PTR 02AA01AC4614020D.local., (Cache flush) A 10.10.20.223, (Cache flush) PTR 02AA01AC4614020D.local., (Cache flush) HINFO, (Cache flush) AAAA fe80::1ab4:30ff:fe16:71e (224)

12:43:28.058898 IP6 fe80::1ab4:30ff:fe16:71e.mdns > ff02::fb.mdns: 0*- [0q] 2/0/0 (Cache flush) PTR 02AA01AC4614020D.local., (Cache flush) A 10.10.20.223 (89)

12:43:29.153733 IP 10.10.20.223.mdns > 224.0.0.251.mdns: 0*- [0q] 5/0/0 (Cache flush) PTR 02AA01AC4614020D.local., (Cache flush) A 10.10.20.223, (Cache flush) PTR 02AA01AC4614020D.local., (Cache flush) HINFO, (Cache flush) AAAA fe80::1ab4:30ff:fe16:71e (224)

12:43:29.163032 IP6 fe80::1ab4:30ff:fe16:71e.mdns > ff02::fb.mdns: 0*- [0q] 2/0/0 (Cache flush) PTR 02AA01AC4614020D.local., (Cache flush) A 10.10.20.223 (89)

12:43:29.300724 IP 10.10.20.152.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _googlecast._tcp.local. (40)

avahi-browse -a

but

./nodecastor/bin/chromecast discover

* WARNING * The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.

* WARNING * Please fix your application to use the native API of Avahi!

* WARNING * For more information see http://0pointer.de/avahi-compat?s=libdns_sd&e=node&f=DNSServiceRegister

Still no results returned.

(restart of avahi-daemon:)

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Found user 'avahi' (UID 70) and group 'avahi' (GID 70).

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Successfully dropped root privileges.

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: avahi-daemon 0.6.25 starting up.

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Successfully called chroot().

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Successfully dropped remaining capabilities.

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Loading service file /services/ssh.service.

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.10.20.13.

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: New relevant interface eth0.IPv4 for mDNS.

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Network interface enumeration completed.

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Registering new address record for fe80::a8e0:7aff:fe99:ffe on eth0.*.

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Registering new address record for 10.10.20.13 on eth0.IPv4.

Mar 24 12:47:57 ykf-dash-1 avahi-daemon[26005]: Registering HINFO record with values 'X86_64'/'LINUX'.

Mar 24 12:47:58 ykf-dash-1 avahi-daemon[26005]: Server startup complete. Host name is ykf-dash-1.local. Local service cookie is 569561208.

Mar 24 12:47:59 ykf-dash-1 avahi-daemon[26005]: Service "ykf-dash-1" (/services/ssh.service) successfully established.

On Mon, Mar 23, 2015 at 5:59 PM, Vincent Bernat notifications@github.com wrote:

❦ 23 mars 2015 13:56 -0700, Graham Dunn notifications@github.com :

iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Nope.

There are a ton of wireless clients and 10+ chromecasts on this network, I would expect to see a bunch of traffic. Maybe there is some logs about avahi in /var/log/messages that would explain that? Or you could try to restart avahi-daemon, maybe it is stuck in some bad state. You could also check with tcpdump that you are receiving mDNS (tcpdump

-pni eth1 port 5353 and not src host yourip).

What no spouse of a writer can ever understand is that a writer is working

when he's staring out the window.

Reply to this email directly or view it on GitHub: https://github.com/vincentbernat/dashkiosk/issues/20#issuecomment-85221817

vincentbernat commented 9 years ago

❦ 24 mars 2015 09:49 -0700, Graham Dunn notifications@github.com :

avahi-browse -a

  • eth0 IPv4 c8:85:50:83:5e:fd@fe80::ca85:50ff:fe83:5efd _ apple-mobdev2._tcp local
  • eth0 IPv4 f0:24:75:a7:4b:91@fe80::f224:75ff:fea7:4b91 _ apple-mobdev2._tcp local
  • eth0 IPv4 18:af:61:4d:ff:c3@fe80::1aaf:61ff:fe4d:ffc3 _ apple-mobdev2._tcp local
  • eth0 IPv4 f0:db:e2:4d:01:39@fe80::f2db:e2ff:fe4d:139 _ apple-mobdev2._tcp local
  • eth0 IPv4 ykf-dash-1 SSH Remote Terminal local
  • eth0 IPv4 ykf-dash-1 [aa:e0:7a:99:0f:fe] Workstation local
  • eth0 IPv4 18:af:61:4d:ff:c3@fe80::1aaf:61ff:fe4d:ffc3 _ apple-mobdev2._tcp local
  • eth0 IPv4 18:af:61:4d:ff:c3@fe80::1aaf:61ff:fe4d:ffc3 _ apple-mobdev2._tcp local

Still no Chromecast here. Also, that's a bit odd that the services are labelled "IPv4" while only IPv6 addresses were learned. In the logs, avahi is also listening for IPv4. Could you check with "netstat -gn" if you are correctly subscribed to 224.0.0.251 for eth1 (I assume yes, because on most setups, the packets received on 224.0.0.251 would have been dropped).

I don't really know what is happening but as long as avahi-browse is not able to see the Chromecasts, Dashkiosk (through nodecastor) won't be able too: it queries Avahi too. Maybe enabling some debugging of

avahi-daemon?

Indent to show the logical structure of a program.