Handle differently structured Bonjour annoucements

[phillipivan]

Is this a feature relevant to companion itself, and not a module?

• I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• I have searched the existing issues

Describe the feature

The companion bonjour utility can only handle announcements that are structured a certain way. This means other devices with valid announcements that aren't structured the way Companion is expecting aren't presented as options in the bonjour config field.

This was discussed on slack here.

@Julusian noted:

The library is expecting a PTR record of name _ssc._udp.local which points to a domain of something like my-device-name._ssc._udp.local . That is missing in your packet.
Then it needs a SRV record against my-device-name._ssc._udp.local , and optionally a TXT record.
Finally, it needs an A record for the 'target' given by the SRV
I don't know why it 'needs' that PTR record, it doesn't seem to really do anything

The devices that initial triggered this discussion were some Sennheiser Digital 6000 series Radio microphone receivers and battery chargers.

MDNS pcap attached.
L6000mdnspcap.zip

Usecases

Enable discovery of broader range of devices via bonjour.

[Julusian]

Reading more into the spec of dns-sd https://www.ietf.org/rfc/rfc6763.txt (in particular section 4.1), it says

This document borrows the logical service-naming syntax and semantics
from DNS SRV records, but adds one level of indirection. Instead of
requesting records of type "SRV" with name "_ipp._tcp.example.com.",
the client requests records of type "PTR" (pointer from one name to
another in the DNS namespace) [RFC1035].

Which the capture you have provided does not do.

What your capture shows is section 9:

For this purpose, a special meta-query is defined. A DNS query for
PTR records with the name "_services._dns-sd._udp." yields a
set of PTR records, where the rdata of each PTR record is the two-
label name, plus the same domain, e.g.,
"_http._tcp.". Including the domain in the PTR rdata allows
for slightly better name compression in Unicast DNS responses, but
only the first two labels are relevant for the purposes of service
type enumeration. These two-label service types can then be used to
construct subsequent Service Instance Enumeration PTR queries, in
this or others, to discover instances of that service type.

meaning that the data in this capture does not conform to the spec, so making it work will have to be a hack specific to the quirk of this hardware.

Additionally, I've noticed that the A record has a ttl of 0, which the library is interpreting as the device saying 'goodbye, please forget me'.
Is this definitely a good capture, or could this be the device shutting down?

[phillipivan]

I believe this is a good capture, device was definitely not shutting down. But will take same more as a sanity check this morning and attach to this thread.

[phillipivan]

em6000_mdns_announce.zip
@Julusian some more MDNS packets from another device in the same product range attached.

[Julusian]

@phillipivan thanks, that one looks more correct.
This one has a correctly formed PTR, although the A does still have a ttl of 0.
I'll need to read more into how this should be handled, from a glance it sounds like this is incorrect, but the library is supposed to handle this differently than it has. So it is sounding more and more like the current library is not conforming in a few ways, so I am wondering if I should be thinking about writing something new from scratch. Of course testing that won't be easy...

[phillipivan]

FWIW, the quick tool I use for checking mDNS announcements, Bonjour Browser, seems to report these announcements without any indication there is a problem. At least some of the time (but I think that's because it's on a vlan with probably ~200 devices making mDNS announcements so it's busy, and BB seems to intermittently miss stuff).