[Printing-architecture] DNS-SD advertising of local services on Linux

Till Kamppeter till.kamppeter at gmail.com
Fri Aug 2 17:57:30 UTC 2019


Hi,

the development on IPP driverless printing standards and there 
implementation has created the demand of DNS-SD-advertising local 
services (on localhost).

At first there is IPP-over-USB, the standard for driverless printing on 
USB printers. For this a daemon on the host machine, ippusbxd emulates 
an IPP printer, and as USB printers are usually visible and accessible 
only on the machine where they are connected to, ippusbxd does the 
DNS-SD advertising of the printer (which is a requirement of the 
driverless IPP printing standards) only on the local machine, under the 
host name "localhost" and therefore via the "lo" network interface, the 
loopback interface.

The same will happen for Printer Applications (Dheeraj Yadav is working 
on a framework to convert legacy drivers in this year's GSoC). If there 
is a USB (or parallel, or serial, or proprietary local connection, ...) 
printer which does not do driverless, so requires a driver, will get a 
Printer Application which emulates an IPP printer and passes on the jobs 
to the actual printer. It again will advertise itself on "localhost" as 
it is for a locally connected printer.

On Linux, DNS-SD (mDNS, Bonjour, Zero-Conf) broadcasting is done by 
Avahi (https://github.com/lathiat/avahi/) and in its currently released 
version Avahi does not support advertising services on "localhost" via 
the loopback device and so it does not advertise the above-mentioned 
services and whe letting these services advertise on other interfaces 
they appear in the whole network behind the interface, effectively 
sharing the printer on the network.

Therefore I have created a simple patch (together with Rithvik 
Patibandla, former GSoC student for OpenPrinting) to add appropriate 
support to Avahi. I have created a first part which actually added the 
loopback interface support but the reported DNS-SD records for the 
service via the loopback device show the correct 127.0.0.1 IP address 
but the machine's network host name and not "localhost" as hostname. A 
client picking up this record and using the hostname for building the 
printer URi would end up not being able to access the printer. Rithvik 
then added a second part to the patch to correct the host name to 
"localhost".

I have published the patch first in the README of ippusbxd:

https://github.com/OpenPrinting/ippusbxd/blob/master/readme.md

and posted it to an Issue report to Avahi:

https://github.com/lathiat/avahi/issues/125

Trent Lloyd, upstream maintainer and one of the original authors of 
Avahi is very much involved in his day job, unfortunately, and so he 
needed a rather long time to answer the request, even being the original 
poster of the Issue.

On March 28 this year he finally gave his first opinion about the patch 
telling that he would only accept my part of the patch which actually 
adds the loopback support and not Rithvik's which corrects the 
"localhost" host name. He tells that the exception handling has to be 
done by CUPS and not by Avahi. See Trent's first comment of March 28.

While fixing a bug in cups-browsed 
(https://github.com/OpenPrinting/cups-filters/issues/136, reported by 
Dheeraj) I have investigated the Avahi case more and came to the 
conclusion that the host name has to get fixed in Avahi.

As Trent also told in his first comment on March 28, a service is 
reported on each network interface it is available on separately and 
independently (my investigations resulted in each combination of network 
interface (lo, eth0, wlan1, ...), service type (IPP, IPPS), and network 
address protocol (IPv4, IPv6)). Each reported record contains service 
name, service type, domain, interface, host name, IP address, address 
protocol, port, and optionally a TXT record with service-specific 
content. It must always be possible to talk to the service using the 
interface/IP/port or interface/hostname/port combo of this record.

This usually works, assuming that the printer does not report its 
presence on an interface/service type/address protocol combo where it 
does not actually listen on. On all non-loopback interfaces the network 
host name is valid and resolves to the IP on the appropriate interface, 
only with the loopback DNS-SD record this does not work if only my and 
not Rithvik's part of the Avahi patch is applied, as the record then has 
the network host name as hostname and not "localhost" and the network 
host name never resolves to the 127.0.0.1 (or ::1) IP address.

As this would not only happen with CUPS as client but also with any 
other client trying to connect to a local service this should be fixed 
in Avahi in my opinion.

See my comments from July 31 to August 2 on

https://github.com/lathiat/avahi/issues/125

for more info.

Now I would like to ask Michael Sweet and also the networking experts 
here what would be the best to solve this problem so that we can have 
all IPP driverless printing standards correctly working on Linux.

Thanks in advance.

    Till



More information about the Printing-architecture mailing list