Crashes with multicast = true, without nothing is found. Only works without any options...

[joeherold]

the bonjour services crashes, with multicast turned on:

var options = {
            multicast: true, // use udp multicasting
            interface: 'eth', // explicitly specify a network interface. defaults to all
            port: 5353, // set the udp port
            ip: '10.0.1.130', // set the udp ip
            ttl: 255, // set the multicast ttl
            //loopback: true, // receive your own packets
            //reuseAddr: true // set the reuseAddr option when creating the socket (requires node >=0.11.13)
        }
var bonjour = require('bonjour')(options);

ERROR:

gram.js:438
    throw errnoException(err, 'addMembership');
    ^

Error: addMembership EINVAL
    at exports._errnoException (util.js:870:11)
    at Socket.addMembership (dgram.js:438:11)
    at Socket.<anonymous> (/path/to/project/node_modules/multicast-dns/index.js:51:14)
    at emitNone (events.js:72:20)
    at Socket.emit (events.js:166:7)
    at startListening (dgram.js:121:10)
    at dgram.js:220:7
    at nextTickCallbackWith3Args (node.js:452:9)
    at process._tickCallback (node.js:358:17)

but turning multicast off, results in not publishing service.

just calling

var bonjour = require('bonjour')(); // here without the options

seems to work, BUT, address is not published.

Output with find look like this:

Found a PLIIGO-BOX server:
 { addresses: [],
  name: 'pliigo',
  fqdn: 'pliigo._pliigobox._tcp.local',
  host: 'pliigo',
  port: 5002,
  type: 'pliigobox',
  protocol: 'tcp',
  subtypes: [],
  rawTxt: <Buffer 00>,
  txt: {} }

When publishing the service with avahi-daemon, then the address is published on the same machine.

[joeherold]

this is published with this bonjour module

_pliigobox._tcp.local { id: 0,
  type: 'response',
  qdcount: 0,
  ancount: 1,
  nscount: 0,
  arcount: 2,
  questions: [],

  answers: 
   [ { name: '_pliigobox._tcp.local',
       type: 'PTR',
       class: 1,
       ttl: 28800,
       flush: false,
       data: 'pliigo._pliigobox._tcp.local' } ],

  authorities: [],

  additionals: [] }

this is published with avahi-daemon

_pliigobox._tcp.local { id: 0,
  type: 'response',
  qdcount: 0,
  ancount: 5,
  nscount: 0,
  arcount: 0,
  questions: [],

  answers: 
   [ { name: '_pliigobox._tcp.local',
       type: 'PTR',
       class: 1,
       ttl: 4500,
       flush: false,
       data: 'pliigo-box._pliigobox._tcp.local' },

     { name: 'pliigo-box._pliigobox._tcp.local',
       type: 'TXT',
       class: 1,
       ttl: 4500,
       flush: true,
       data: <Buffer 00> },

     { name: 'pliigo-box._pliigobox._tcp.local',
       type: 'SRV',
       class: 1,
       ttl: 120,
       flush: true,
       data: [Object] },

     { name: 'pliigo.local',
       type: 'AAAA',
       class: 1,
       ttl: 120,
       flush: true,
       data: 'fe80::4800:47fd:7253:c7ac' },

     { name: 'pliigo.local',
       type: 'A',
       class: 1,
       ttl: 120,
       flush: true,
       data: '10.0.1.130' } ],
  authorities: [],

  additionals: [] }

[watson]

@joeherold Thanks for opening the issue :smiley: The problem you discovered is related to the format of the interface option. It's supposed to be the IP of the interface you want to bind to, not the name. The documentation of the multicast-dns module was wrong in sugesting to use the name. I've updated it now to reflect this.

In most case however you don't need to set any options here. The default options are what you need in most cases. In case of the interface option, it will broadcast on all interfaces if none is specified.

Does this solve your problem?

[joeherold]

@watson thx! but why isn't it publishing an answer of type "A" (or "AAAA") to provide the IPv4 (or IPv6)?

[joeherold]

@watson the addresses array stays empty...

is it possible, that this is not implemented in this module, that it publishes the additional data in an PTR or SRV call?

[watson]

@joeherold I've not yet found a good way to get the autoritative TTL for the A and AAAA records from within node. I can make it up of cause, but that doesn't seem nice, so for now I've left them out (and basically letting it up to the client to look them up). But it's on my todo list. Is it important for you that they are returned in the response or what's your use case?

[joeherold]

@watson in avahi-daemon the TTL für A and AAAA is 120 per default

my usecase is a little raspberry pi, that has a web service for an mobile app (ios/android), that should connect through an http(s) request. so i want to provide the IP directly with the provided service. but actually I provide the service over avahi-daemon, but I would prefere do do all on nodejs :)

[joeherold]

because I fell in love with nodejs

[joeherold]

but it is not urgent. currently I work on an nodejs cli tool to manage a cups server (installing and managing printers/queues)

and this will take its time, because implementing the driver selection (gutenprint) is tough

[joeherold]

@watson to complete my answer... through a VPN the hostname often is not resolved, therefore I need the IPv4/v6

[eshober]

@watson For the record, I would also like to get the A response from this bonjour module. As a workaround I'm setting the IP address and port as TXT records but that's not how I'd like it to work. Also, I'd like to use Bonjour Browser on Android but my service that uses this bonjour module isn't listed properly.

I'm confused, isn't the main reason for discovery to get the IP address? (At least it is for me)

Otherwise, I'm very pleased with how it works. It seems nicer to work with than other discovery packages for node.js that I tried. Thanks!

[watson]

@eshober if your OS have support for the local link lookup (not sure if that's the correct word), then you normally don't need the IP. Say I have an Apple TV with the name "Apple TV", then the local link address would normally just be Apple-TV.local and if you tried to ping that hostname your OS would automatically look up the IP for it and it would just work. I'm not sure though if Windows supports this stuff, so I totally get that it would be a good feature to add 😃

[eshober]

@watson To give a little more context. I have a small device connected on the LAN running Lubuntu. Currently, it does not respond on .local. Also, I would like users to be able to discover a web service (node.js/bonjour) running on the device from their Android phones. The device does not appear in the list at all on my phone using Bonjour Browser, ZeroConf Browser or NetX. I'm assuming this is because it's not returning an A response but not sure.

[watson]

@jlucidar @eshober #12 have just been merged into master and is published in v3.4.0. That should fix this issue. Please reopen if it turns out not to 😃