Difference between revisions of "Bonjour/ZeroConf"

Latest revision as of 14:28, 11 December 2008

An mDNS "responder" is a daemon which runs on a device, and when it sees a multicast message of the form "where is Elvira.local?" it responds with the IP address, assuming that machine on which the responder is running is named Elvira. Usually each machine can only answer for itself; machines which do not have the authoritative answer will not reply. Sort of like a roll call in a class... But not every device has a responder available for it, so using avahi, you can add the name/address mappings for such machines in /etc/avahi/hosts.

There is also the concept of an mDNS "reflector" whose job apparently is to act as a gateway between two or more networks, causing queries and replies on one network to also be sent out on the other network.

mDNS can also be used to find services; this feature is called dns-sd (DNS service discovery).

On Gentoo the choices for a responder daemon are avahi and mDNSResponder. avahi is more full-featured and includes client programs like avahi-discover (to find devices and services on the network) and avahi-publish (a daemon which announces a service or a device, on behalf of one that cannot announce it itself).

The specs for mDNS/Bonjour/ZeroConf/Rendezvous (all different names for the same thing) are here.

OpenWRT

It would appear that the mDNSResponder on OpenWRT acts as a reflector (?); what I observe is that queries from WiFi can be answered by machines on the LAN. Or it could be that this behavior is caused by iptables rules rather than the responder itself.

CUPS printers

Bonjour for Windows includes a Bonjour Printer Wizard which can find Bonjour-enabled printers on the network and automatically install them in the Printers control panel. I would hope that some day CUPS would register printers automatically, but for now it seems not to. I run avahi on my CUPS server; so announcing the printer was just a matter of creating a file /etc/avahi/services/laserwriter.service, like this:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name>LaserWriter</name>
  <service>
    <type>_ipp._tcp</type>
    <port>631</port>
    <txt-record>path=/printers/LaserWriter</txt-record>
    <txt-record>rp=printers/LaserWriter</txt-record>
    <txt-record>note=Multimedia Room</txt-record>
        <txt-record>qtotal=1</txt-record>
        <txt-record>ty=Apple LaserWriter 600</txt-record>
        <txt-record>>adminurl=http://muon:631/printers/LaserWriter</txt-record>
        <txt-record>Color=F</txt-record>
        <txt-record>Duplex=F</txt-record>
        <txt-record>Bind=F</txt-record>
        <txt-record>Collate=F</txt-record>
        <txt-record>Sort=F</txt-record>
        <txt-record>Staple=F</txt-record>
        <txt-record>Punch=F</txt-record>
        <txt-record>PaperMax=legal-A4</txt-record>
  </service>
</service-group>

I figured out how based on this and the spec.

When I use the wizard on Windows, the result is that it adds a printer using the "Internet Port" http://muon.local:631/printers/LaserWriter-raw. One feature I would like to have, is if I rename the server, or I move the printer from one server to another, it should still be found. Unfortunately Windows has to have the hostname, so I'm not sure how to achieve this result. Windows probably ought to be doing the service discovery each time you print, and finding the service of the same name as configured, rather than looking for the hostname. One way I solved it with regular DNS (running bind on one of my servers) is to create a CNAME pointing printer.lan to the actual server, so if I move the printer I just change the CNAME mapping. I have not figured out how to do that with mDNS.

SlimServer

SlimDevices was a bit of a pioneer in that the Squeezebox has always used mDNS to find the SlimServer instance(s) running on the network. Being pioneers, they assumed that the Linux box would not already have an mDNS responder; so they bundled mDNSResponder with the tarball (which also includes some perl modules, the source for SQLite, and other things they expected would not be installed by default on a typical plain-Jane Linux distro). I'm not a fan of this bundling because you can end up with redundant versions of things and version conflict problems. If they could distribute a "universal binary" for the entire slimserver that is one executable with everything statically linked, this wouldn't be such a problem and would work well for RedHat users and such. But mDNS kindof has to be separate, because there can be only one. So far the Gentoo ebuild for slimserver has mDNSResponder as a dependency. If you want to use avahi, just install slimserver and mDNSResponder first, then unmerge mDNSResponder and merge avahi. I put in a bug report asking for this to be changed - it should work with either one based on a USE flag, most likely.

Fedora Core 6

Avahi works. There doesn't seem to be a package for /lib/libnss_*mdns*.so though, so I had to compile and install it from source, which was also straightforward.