node_mdns: Raspberry PI 2 getaddrinfo 3008 error

I guess you’ve found out by now, but for future reference you can change this:

var browser = mdns.createBrowser(mdns.tcp('http'));

into this:

var sequence = [
    mdns.rst.DNSServiceResolve(),
    'DNSServiceGetAddrInfo' in mdns.dns_sd ? mdns.rst.DNSServiceGetAddrInfo() : mdns.rst.getaddrinfo({families:[4]}),
    mdns.rst.makeAddressesUnique()
];
var browser = mdns.createBrowser(mdns.tcp('http'), {resolverSequence: sequence});

That resolver sequence made it work for me on Raspberry Pi.

Hello, I have the same kind of problem with either io.js 1.6.4 or node 0.12.2 I found use the following workaround: adding this line mdns.Browser.defaultResolverSequence[1] = 'DNSServiceGetAddrInfo' in mdns.dns_sd ? mdns.rst.DNSServiceGetAddrInfo() : mdns.rst.getaddrinfo({families:[4]}); right after the require. var mdns = require('mdns');

Look like the issue on my machine is with resolving IPv6 addresses. I have a tempoarary workaround (for me at least). If I modify Browser.defaultResolverSequence in lib/browser.js to only use IPv4 my issue goes away.

here is my new Browser.defaultResolverSequence:

Browser.defaultResolverSequence = [
  rst.DNSServiceResolve()
, 'DNSServiceGetAddrInfo' in dns_sd ? rst.DNSServiceGetAddrInfo() : rst.getaddrinfo({families:[4]})
, rst.makeAddressesUnique()
];

After some debugging on debian/stretch, I’ve found some more info on this : error -3008 is from uv_getaddrinfo, returning UV__EAI_NONAME, which is -3008 (ref.)

It’s not “normal behaviour” as the service has been detected so there must be a way to reach it.

Meanwhile, a more intuitive handling might be done by modifying lib/resolver_sequence_tasks.js :109

  function getaddrinfo_complete(err, addresses, cb) {
    if (addresses) {
      cb(undefined, addresses);
-    } else if (err === 'ENOENT') {
+   } else if (err === 'ENOENT' || err == -3008) {
      cb(undefined, []);
    } else {
      cb(errnoException(err, 'getaddrinfo'));
    }
  }

I’m not even sure getaddrinfo could return ‘ENOENT’ btw?

Concerning the core issue of having a service without any valid reaching address, I’m still looking into it but as previously said by others, it most probably comes from a malformed network stack configuration.