If the service name is too long, printer does not get advertized via DNS-SD

[Till Kamppeter]

Binary package hint: cups

I have several print queues on a print server and they have rather verbose descriptions in their Description/Info fields. The patch to make CUPS' DNS-SD broadcasting of print queues also working with Avahi generates DNS-SD service names as "<CUPS description> @ <Server host name>". Avahi only allows strings with a maximum of 63 characters as service names and the service names generated by the patch are often too long. The printers with too long service names do not get DNS-SD-advertized as Avahi does not accept them.

I have modified the Avahi patch so that in case of too long description strings, they get cut to assure that the service name is never longer than 63 characters.

The attached patch contains the changes and applies to the scheduler/dirsvc.c file after applying the debian/patches/cups-avahi.patch.

[Till Kamppeter (till-kamppeter)]

Tim, can you apply this chabge to the CUPS Avahi patch upstream? Thanks.

[Till Kamppeter (till-kamppeter)]

The attached patch is an update of the patch to add Avahi support to CUPS 1.4.x (file debian/patches/cups-avahi.dpatch in the Debian/Ubunmtu package of CUPS). It fixes bug 792309, bug 711779, and this bug. With this update sharing printers via DNS-SD (especially to Mac OS X and to iPhone and iPad) should actually work.

[Till Kamppeter (till-kamppeter)]

The updated patch is now included in Debian's BZR repository of CUPS, so it will get into the next CUPS packages on Debian unstable and Ubuntu Oneiric.

[Till Kamppeter (till-kamppeter)]

A fixed CUPS package for Natty is now uploaded the -proposed queue. As soon as it gets approved please test the new package. A comment with instructions will be posted here then. A debdiff of the changes is attached.

The new CUPS package does not fix only this bug, but in total five bugs (therefore the somewhat bigger debdiff): bug 711779, bug 782309, bug 790378, bug 792309, bug 793265. Any help on verifying these fixes is also welcome.

[Till Kamppeter (till-kamppeter)]

Tim, here is an update of cups-avahi.patch of comment #3. It contains also the addition of the subtype "_universal" (see bug 711779).

[Martin Pitt (pitti)]

Accepted cups into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Launchpad Janitor (janitor)]

This bug was fixed in the package cups - 1.4.6-7

---------------
cups (1.4.6-7) unstable; urgency=low

  * debian/patches/cups-avahi.dpatch: Updated Avahi patch so that it does
    not generate too long service names which Avahi does not accept. Printers
    did not get advertized via DNS-SD then. (LP: #793265).
  * debian/patches/cups-avahi.dpatch: Updated Avahi patch to add the text
    field entry "URF=none" and the service subtype "_universal" so that
    mDNS/Bonjour-advertized printers are recognized by AirPrint clients
    (iPhone/iPad with iOS 4.2 or newer). (LP: #711779).
  * debian/patches/cups-avahi.dpatch: In contrary to the libdns_sd API the
    Avahi API requires port numbers in host order and not in network order.
    This made the Avahi-based DNS-SD broadcasting of CUPS advertizing wronmg
    port numbers. Updated the Avahi patch to fix it. Thanks to Tim Waugh
    from Red Hat on confirming this (LP: #792309).
  * debian/local/filters/pdf-filters/pdftopdf/P2PResources.cxx: Fixed
    memory leak in pdftopdf filter which made the filter taking up several
    gigabytes when processing certain PDF files. Thanks to upstream
    author Koji Otani for the quick fix (LP: #790378).
  * debian/local/pstopdf.convs, debian/local/pstopdf.types: Do not apply
    the PDF printing workflow to PostScript input coming from the Adobe
    Reader. If this PostScript comes from an encrypted (DRM) PDF, it cannot
    be converted to PDF again by Ghostscript (LP: #782309).
 -- Martin Pitt <email address hidden> Tue, 07 Jun 2011 07:04:11 +0200

[Till Kamppeter (till-kamppeter)]

The package in natty-proposed fixes the problem.

[Tim Waugh (twaugh)]

Till, what if strlen(DNSSDComputerName) > AVAHI_LABEL_MAX - 4? Wouldn't that underflow the buffer? (Besides the fact that calling strlen() several times on the same string in the same expression is ugly...)

Here's the fix I'm planning on going with.

[Till Kamppeter (till-kamppeter)]

Tim, is this patch really complete? To what state of dirsvc.c does it apply? It adds only the include line for avahi-common/domain.h and replaces the declaration of the "name" variable for the use of Avahi. Nothing more.

[Tim Waugh (twaugh)]

That's right -- the include is for AVAHI_LABEL_MAX, and if we declare name[] to be that long then the existing checks (snprintf, strlcpy) will already truncate the name. sizeof(name) is AVAHI_LABEL_MAX now.

[Till Kamppeter (till-kamppeter)]

Tim, your approach has one problem: If the description/info field of the CUPS queue gets too long, the server name in the service name will get cut off. So a user sees only the description, but not from which server the queue comes. We need to improve my approach that a too long server name gets truncated, with "too long" defined so that the result is a service name containing both a part of the server name and of the queue description, for example cut the server name at 30 characters. If the server name is shorter, or after truncating it, follow my approach.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cups - 1.4.6-5ubuntu1.2

---------------
cups (1.4.6-5ubuntu1.2) natty-proposed; urgency=low

  * debian/patches/cups-avahi.dpatch: Updated Avahi patch so that it does
    not generate too long service names which Avahi does not accept. Printers
    did not get advertized via DNS-SD then. (LP: #793265).
  * debian/patches/cups-avahi.dpatch: Updated Avahi patch to add the text
    field entry "URF=none" and the service subtype "_universal" so that
    mDNS/Bonjour-advertized printers are recognized by AirPrint clients
    (iPhone/iPad with iOS 4.2 or newer). (LP: #711779).
  * debian/patches/cups-avahi.dpatch: In contrary to the libdns_sd API the
    Avahi API requires port numbers in host order and not in network order.
    This made the Avahi-based DNS-SD broadcasting of CUPS advertizing wronmg
    port numbers. Updated the Avahi patch to fix it. Thanks to Tim Waugh
    from Red Hat on confirming this (LP: #792309).
  * debian/local/filters/pdf-filters/pdftopdf/P2PResources.cxx: Fixed
    memory leak in pdftopdf filter which made the filter taking up several
    gigabytes when processing certain PDF files. Thanks to upstream
    author Koji Otani for the quick fix (LP: #790378).
  * debian/local/pstopdf.convs, debian/local/pstopdf.types: Do not apply
    the PDF printing workflow to PostScript input coming from the Adobe
    Reader. If this PostScript comes from an encrypted (DRM) PDF, it cannot
    be converted to PDF again by Ghostscript (LP: #782309).
 -- Till Kamppeter <email address hidden> Mon, 5 Jun 2011 13:51:59 +0200

[Tim Waugh (twaugh)]

This sort of thing ought to work. What do you think?

It applies to upstream 1.4 (current SVN), and should be applied upstream. It's a separate issue from avahi support.

[Till Kamppeter (till-kamppeter)]

Thank you for the patch, but it will not work when adding after applying the current cups-avahi.dpatch, removing my patch from comment #1, then applying your patch from comment #10 and finally adding your patch from comment #15. The variable nameptr is defined only for the libdnssd case. It must be moved out of the #ifdef's.

[Till Kamppeter (till-kamppeter)]

Tim, with your patch correctly integrated, the cups-avahi.dpatch for CUPS 1.4.6 is the attached one.

[Till Kamppeter (till-kamppeter)]

I have another suggestion for improvement of the service name handling: Let us assure 15 instead of 6 characters for the server name. This gives enough space for an IP address.

[Tim Waugh (twaugh)]

Another improvement: don't require 15 characters of room if DNSSDComputerName is shorter than that.