Bonjour (mDNS) stopped working after updating OmniOS

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

nle

Member
Oct 24, 2012
204
11
18
Hi guys,

I updated Omnios to omnios-8c08411 and all packages to the newest available, that made Bonjour/mDNS stop working. So the server will no longer broadcast the AFP share.

The AFP share still works if you connect manually.

I can not see anything special in the log files. I have tried restarting afp, restarting server and finally reinstalling Napp-IT.

I can get it working by manually adding a line to the mDNS settings of Napp-IT, but the RackMac model does not work. And previously it worked without needing to add anything.

If you need any more info, please ask! Thank you!
 

nle

Member
Oct 24, 2012
204
11
18
Ok, I figured out how to fix this manually. @gea: Maybe you could update the description in Napp-IT?

The thing is that the existing line in the documentation in napp-it states that you can set the model in the line that advertises the service (_afpovertcp._tcp), but you can not. You need to add a second line with "_device-info._tcp.".

So the final command in the napp-it interface looks like this. The second line is the one that sets the model-icon.
Code:
dns-sd -R "hostname" _afpovertcp._tcp local. 548 & 
dns-sd -R "hostname" _device-info._tcp. local 548 model=Xserve &
 

nle

Member
Oct 24, 2012
204
11
18
@gea I'm looking into to this again trying to get TimeMachine to work over SMB, and I think the deviceinfo part is wrong (even though it sort of work).

I think this is the correct way (ref. this mailing list post):
Code:
dns-sd -R "hostname" _device-info._tcp. TXT model=Xserve &
So the whole thing for the SMB service will be:
Code:
dns-sd -R "hostname" _smb._tcp local. 445 &
dns-sd -R "hostname" _device-info._tcp. TXT model=Xserve &
EDIT: I edited the order of the two lines. Service first, then model.
 
Last edited:
  • Like
Reactions: gea

natkin

New Member
Jul 14, 2016
15
1
3
@gea
So the whole thing for the SMB service will be:
Code:
dns-sd -R "hostname" _device-info._tcp. TXT model=Xserve &
dns-sd -R "hostname" _smb._tcp local. 445 &
dns-sd(1M) disagrees with your proposal. The documented syntax for registration is:

dns-sd [-R name type domain port [key=value ...]]
...
Additional attributes of the service may optionally be described by
key/value pairs, which are stored in the advertised service's DNS TXT
record​

in accordance with napp-it's current usage. One deviation is that "local." is not documented as a valid domain ("local" and "." are correct) but it does seem to work on my systems.
 

nle

Member
Oct 24, 2012
204
11
18
The mailing list post I linked in the last post seems legit. It works and seems reasonable that you don't really need any port information to set a device model other than the "name" linking them together.

But I must admit I don't really have a clue about this issue, other than what worked for me or not.

I dug up this, from one of the sources in this post:

4.1.3 Domain Names

The <Domain> portion of the Service Instance Name specifies the DNS
subdomain within which the service names are registered. It may be
"local.", meaning "link-local Multicast DNS" [mDNS],
or it may be
a conventional unicast DNS domain name, such as "ietf.org.",
"cs.stanford.edu.", or "eng.us.ibm.com." Because service names are
not host names, they are not constrained by the usual rules for host
names [RFC 1033][RFC 1034][RFC 1035], and rich-text service
subdomains are allowed and encouraged, for example:

Building 2, 1st Floor . example . com .
Building 2, 2nd Floor . example . com .
Building 2, 3rd Floor . example . com .
Building 2, 4th Floor . example . com .

In addition, because Service Instance Names are not constrained by
the limitations of host names, this document recommends that they
be stored in the DNS, and communicated over the wire, encoded
as straightforward canonical precomposed UTF-8 [RFC 3629]
"Net-Unicode" (Unicode Normalization Form C) [RFC 5198] text.
In cases where the DNS server returns a negative response for the
name in question, client software MAY choose to retry the query using
the "Punycode" algorithm [RFC 3492] to convert the UTF-8 name to an
IDNA "A-label" [RFC 5890], beginning with the top-level label, and
then issuing the query repeatedly, with successively more labels
translated to IDNA A-labels each time, and giving up if it has
converted all labels to IDNA A-labels and the query still fails.
 
Last edited:

natkin

New Member
Jul 14, 2016
15
1
3
The mailing list post I linked in the last post seems legit. It works and seems reasonable that you don't really need any port information to set a device model other than the "name" linking them together.

But I must admit I don't really have a clue about this issue, other than what worked for me or not.

I dug up this, from one of the sources in this post:
I'm sorry, but dns-sd is quite strict about what command-line arguments it needs. Please see the source, Cross Reference: /illumos-gate/usr/src/cmd/cmd-inet/usr.bin/dns-sd/dns-sd.c.

The following is an example using normal arguments:

Code:
# dns-sd -R "hostname" _device-info._tcp. local 445 model=Xserve
Registering Service hostname._device-info._tcp..local port 445 TXT model=Xserve
See how the command infers a TXT record from key=value (i.e., it outputs "TXT" and then regurgitates the fifth and higher arguments after -R).

Here is the output from your proposed command:

Code:
# dns-sd -R "hostname" _device-info._tcp. TXT model=Xserve
Registering Service hostname._device-info._tcp..TXT port model=Xserve
See how dns-sd is using "TXT" as the "domain" (the third argument after -R) and trying to interpret "model=Xserve" (the fourth argument after -R) as the port -- and no TXT content is inferred because there are no fifth and higher arguments. dns-sd.c will literally execute atoi("model=Xserve") at Cross Reference: /illumos-gate/usr/src/cmd/cmd-inet/usr.bin/dns-sd/dns-sd.c.
 
  • Like
Reactions: nle