It does not seem like publish() actually publishes publicly properly

[StefanWallin]

This might be duplicate of #9 or #13, if that's the case I'm sorry!

🥂 🍻 Thanks in advance for great work with open sourcing this. 🎉

I'm trying this on:

• Mac OS Sonoma 14.2.1 on a M1 Apple Silicon
• npx ts-node -v: v10.9.2
• node -v: `v18.13.0
• Discovery.app 2.1.0 (6)

Description

I'm trying to implement the react-native-zeroconf library in my react native app and serve from my server with your bonjour-service, but It does not seem that the announce from this library is reaching the network properly.

If I use the Discovery App I can see services such as Airplay and others, but not whatever I announce from this library.

If I try to scan for airplay over tcp with react-native-zeroconf I get matches from within my iOS simulator I will see my apple TV which is only connected by bluetooth even.

My setup

index.ts

import Bonjour from "bonjour-service";

const init = async () => {
  const instance = new Bonjour();
  console.log("Publishing bonjour service");
  const a = instance.publish({
    name: "TestApp Desktop Server",
    type: "testapp",
    protocol: "tcp",
    port: 3000,
  });

  while (true) {
    // keep the process alive
    await new Promise((resolve) => setTimeout(resolve, 4000));
    console.log("instance", a);
    await new Promise((resolve) => setTimeout(resolve, 2000));
    console.log("Waiting...");
  }
};

init();

It will output something like this:

instance Service {
  _events: [Object: null prototype] {},
  _eventsCount: 0,
  _maxListeners: undefined,
  probe: true,
  published: true,
  activated: true,
  destroyed: false,
  txtService: DnsTxt { binary: undefined },
  name: 'TestApp Desktop Server',
  protocol: 'tcp',
  type: '_testapp._tcp',
  port: 3000,
  host: 'carambola-124.local',
  fqdn: 'TestApp Desktop Server._testapp._tcp.local',
  txt: undefined,
  subtypes: undefined,
  disableIPv6: false,
  start: [Function: bound start],
  stop: [Function: bound stop],
  [Symbol(kCapture)]: false
}
Waiting...

If I use bounjour-service as client it works, but not ideal for a react native environment, and it's weird that other applications cannot see the announcement either.

[StefanWallin]

In contrast, mdns works directly out of the box for me:

mdns.ts

const mdns = require("mdns");

const init = async () => {
  console.log("Publishing bonjour service");
  const ad = mdns.createAdvertisement(mdns.tcp("testapp"), 3000);
  ad.start();

  while (true) {
    // keep the process alive
    await new Promise((resolve) => setTimeout(resolve, 4000));
    console.log("instance", ad);
    await new Promise((resolve) => setTimeout(resolve, 2000));
    console.log("Waiting...");
  }
};

init();

[mdidon]

@StefanWallin Thanks for the heads up. It maybe related to the issues mentioned but I'll have to dig further to see if I can replicate.
I've not personally tested with React Native but I know iOS directly does work. You may however need to set NSBonjourServices in the Info.plist file to allow for scanning.

[mdidon]

@StefanWallin Also, which version of bonjour-service are you using?

[StefanWallin]

• bonjour-service version: 1.2.0
• plist settings for ios app is settled and my app can find other things in the vicinity that are not on the ios sim but on devices outside my macbook.
• Here is a full replication repo:
  https://github.com/StefanWallin/bonjour-service-publication-bug-replication

your client detects both, but mdns-client cannot detect from this library.

[StefanWallin]

I realized that one thing that might be interesting to know is that I'm currently without a stable wifi since I'm in my mountain cabin and not at home. So my current network setup is my macbook relying on being wifi-connected to an iPhone with Internet Sharing turned on and using that as a hotspot.

[JensEggers]

Hi, I've been struggling with a similar issue and have been comparing an implementation based on multicast-dns that works with the Discovery app, with one based on bonjour-service that shows up in Discovery app but does not reveal any further details (such as hostname and IP address).

The difference also manifests in other Mac-based zeroconf browsers (e.g. Zero Conf Browser and LocalSites) in that they can open the advertised website when advertised using multicast-dns, but not when advertised using bonjour-service.

Looking at Wireshark logs (and with my very limited knowledge of DNS) the main difference appears to be that bonjour sends all records in the Answers section, whereas in multicast-dns I was able to copy the behaviour of another working device and send only the PTR record in the Answers section, while sending types SRV, TXT and A in the Additional records section. Perhaps this is what bonjour browsers expect.

multicast-dns response (working)

Multicast Domain Name System (response)
Transaction ID: 0x0000
Flags: 0x8400 Standard query response, No error
Questions: 0
Answer RRs: 1
Authority RRs: 0
Additional RRs: 3
Answers
_http._tcp.local: type PTR, class IN, device-1._http._tcp.local
Additional records
device-1._http._tcp.local: type TXT, class IN, cache flush
device-1.local: type A, class IN, cache flush, addr 10.136.140.2
device-1._http._tcp.local: type SRV, class IN, cache flush, priority 0, weight 0, port 80, target device-1.local

bonjour-service response (not working)

Multicast Domain Name System (response)
Transaction ID: 0x0000
Flags: 0x8400 Standard query response, No error
Questions: 0
Answer RRs: 4
Authority RRs: 0
Additional RRs: 0
Answers
_http._tcp.local: type PTR, class IN, device-2._http._tcp.local
device-2._http._tcp.local: type SRV, class IN, priority 0, weight 0, port 80, target device-2.local
device-2._http._tcp.local: type TXT, class IN
device-2.local: type A, class IN, addr 10.136.140.1

[mdidon]

@JensEggers Thanks for the deeper dive, it is super helpful.
I'll have a further look into this to see what we can do to resolve.