CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting

[Adrian Sampson]

Binary package hint: cups

I've enabled advertising of local printers in a recent upgrade to Karmic. The config file has these salient lines:

Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseRemoteProtocols cups
BrowseAddress @LOCAL
BrowseLocalProtocols cups dnssd

But CUPS still doesn't advertise using DNS-SD. (I can't find the printers with a Mac OS X v10.6 client, and I also checked by running avahi-browse locally.) I turned the log level to debug2 and didn't find any indication that DNS-SD was being used. (In particular, I expected "dnssdRegisterPrinter" to be logged, as reflected by line 2666 of dirsvc.c in the CUPS source.) Suspiciously, I noticed this line in the log file:

d [30/Oct/2009:14:35:13 -0700] [CGI] Starting "{HAVE_DNSSD?" at 2802, result=0...
d [30/Oct/2009:14:35:13 -0700] [CGI] Skip first part...

I don't exactly know what's going on here, but is it possible that CUPS was for some reason compiled with the HAVE_DNSSD flag off?

Further evidence: If I click "Advanced" on the "Administration" page, the protocols under "Share printers connected to this system" are CUPS, LDAP, and SLP. No DNS-SD.

[Adrian Sampson (adrian-radbox)]

Additionally, I notice that the cups package doesn't depend on libavahi-compat-libdnssd1, which provides the dns_sd library. CUPS's configure script checks for dns_sd.h (in libavahi-compat-libdnssd-dev) in order to set HAVE_DNSSD.

I should also note that this was working under Jaunty. I don't recall which version of CUPS it had...

[dude (matt108a-deactivatedaccount)]

I have exactly the same issue. It worked just fine in jaunty but appears to be broken in karmic. I had to fall back to listening to "cups" broadcasts in Mac OS X (which is not on by default there). Apart from that I also tested this on Windows XP (bonjour for windows) and my printer could not be detected there either.

[Thawn (webmaster-korten-privat)]

As a workaround for mac users, the following steps activate listening to cups broadcasts (thus allowing automatic detection of linux shared printers again):

On your mac use a web browser to open:
http://localhost:631/admin/?ADVANCEDSETTINGS=YES

on the right hand side under "server settings" make sure that "Show printers shared by other systems" and "Protocols: CUPS" are checked.

click "save settings"

enter the username and password of an admin account (e.g. your login).

done

[ilia Lobsanov (ilia-lobsanov)]

Thawn: is there a similar workaround for Tiger users?

[ilia Lobsanov (ilia-lobsanov)]

err I meant to say Leopard (10.5.x)

[Thawn (webmaster-korten-privat)]

under Leopard you need to edit the config file manually. You can do that also from the web fronend using your browser
open
http://localhost:631/admin?op=config-server

add

BrowseRemoteProtocols cups

in the section: # Show shared printers on the local network.

click on save changes

good luck ;-)

[Anshuman Aggarwal (anshuman-aggarwal)]

Verified that the issue is reproducible in an upgrade from a jaunty install upgraded to karmic. There is no Bonjour broadcast of the printers happening even with remote protocol dns-sd.

[Thawn (webmaster-korten-privat)]

since this bug might also be caused by avahi, I filed a bug there:

https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/484823

[Venator85 (venator85)]

Any news on this? :)

[Friedrich Graeter (graeter)]

This bug also appears on my system, which is a clean install of karmic. On the other hand, I have an upgraded system, where it still works...

[Jouke (digigram)]

same here on new install of ubuntu 9.10 server edition

[Jeff Long (isorhythmic)]

Same issue here. This is extremely frustrating, as I can print fine from Windows and Linux computers. Is anyone actually trying to fix this? This is a ridiculous thing to have to deal with in such a mature version of Ubuntu. I'm about to go back to Debian for my print server.....

[lunomad (damon-metapaso)]

This issue is also affecting me. The Zeroconf Service Discovery panel applet also shows no printers when "browse services on this machine" is selected in the applet's advanced preferences.

I'm posting only to include another issue and wondering if it's related or separate:

I can view my cups web interface from the server web browser via:

http://localhost:631
http://192.168.0.10:631

but not

http://myserver.local:631

even though a "ping myserver.local" returns hits from 192.168.0.10.

When I try http://myserver.local:631, I get "400 Bad Request".

Could this be related to all the mac machines on my network suddenly being unable to find the server's printers?

[Luke Symes (allsymes)]

Marking as confirmed, as several people have run into this issue, including myself.

[Luke Symes (allsymes)]

Upstream CUPS bug for Avahi Support: http://www.cups.org/str.php?L3066 (not recognized by Launchpad upstream integration).

Found a sad comment on one of it's duplicates:
"Note that this patch is not a complete implementation - it only handles discovery of printers via DNS-SD, it doesn't handle sharing of CUPS printers via DNS-SD."

The problem with Avahi (http://www.avahi.org/ticket/303) is that:
"kDNSServiceFlagsShareConnection is now used throughout CUPS's DNS-SD feature set (CUPS 1.4). This is not implemented in dns_sd.h, so Avahi support is not able to be added to CUPS."

Thus, even if we get CUPS to compile with Avahi support, it won't be able to share printers via DNS-SD.

[Luke Symes (allsymes)]

This bug is a regression from Hardy, as per https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/50230, #8:

Till Kamppeter wrote on 2007-12-18:
Yes, in Hardy we have full DNS-SD support. I have written a simple DNS-SD backend for CUPS based on avahi-browse, so that CUPS discovers network printers and DNS-SD-only broadcasted CUPS queues (for example from Mac OS X boxes) via DNS-SD. system-config-printer distinguishes between network printers and CUPS queues discovered via DNS-SD and in case of CUPS queues it does not assign a driver so that the driver from the server gets used. On the server side CUPS 1.3 broadcasts the local printers via DNS-SD and so Mac clients will find them.

[Noel J. Bergman (noeljb)]

RedHat provided patch: http://cvs.fedoraproject.org/viewvc/devel/cups/cups-avahi.patch?view=markup

[Martin Pitt (pitti)]

Till, we already have RedHat's patch, maybe it was fixed recently?

[Till Kamppeter (till-kamppeter)]

I have checked again now and Red Hat's patch still modifies only the dnssd backend and does not touch the CUPS daemon. So DNS-SD broadcasting/listening is still not working with CUPS 1.4.

[Sense Egbert Hofstede (sense)]

I can confirm that it still doesn't work on Ubuntu Lucid.

[James Troup (elmo)]

Till, can you provide a sketch of the work required to fix this for Lucid. AIUI we don't detect printers that MacOS and WIndows will detect and enable just fine, and that's been the case since Hardy. Can you articulate clearly what it will take to make this Just Work?

(sabdfl from elmo's machine)

[Till Kamppeter (till-kamppeter)]

James, the problem is the following:

In CUPS 1.3.x DNS-SD/Zeroconf broadcasting was implemented using APIs which are available in Avahi, in CUPS 1.4.x other APIs were used which do not exist as Debian/Ubuntu packages. The Avahi implementation of libdns is incomplete. They exist in free software libraries, but these were never touched by Debian or Ubuntu developers.

So the only way to get it into Lucid without introducing completely new packages is either patch CUPS 1.4.x with code of CUPS 1.3.x or to include the libdns with the needed APIs in the CUPS package and link it statically.

[Mark Shuttleworth (sabdfl)]

On 19/03/10 08:39, Till Kamppeter wrote:
> So the only way to get it into Lucid without introducing completely new
> packages is either patch CUPS 1.4.x with code of CUPS 1.3.x or to
> include the libdns with the needed APIs in the CUPS package and link it
> statically.
>

Why can't we package libdns?

Mark

[Till Kamppeter (till-kamppeter)]

Mark, the problem is that we are after Feature Freeze, so we cannot add new packages any more. Or should we do a FF exception here?

[Mark Shuttleworth (sabdfl)]

On 19/03/10 09:50, Till Kamppeter wrote:
> Mark, the problem is that we are after Feature Freeze, so we cannot add
> new packages any more. Or should we do a FF exception here?
>
If it's there, and works, and would fix this bug without other
side-effects, yes we should ask for that.

Mark

[Zerocool3001 (timfall)]

Any idea if this will be included in 10.04 despite feature freeze?

[Jouke (digigram)]

it's not fixed in ubuntu 10.04

[David Sanders (david-dsanders-deactivatedaccount)]

Any news on this chaps? I'm just a frustrated user but can we expect this for Maverick?

[Mark Levitt (mark-marklevitt)]

Yes, some news on this would be good. Although, I don't think waiting for Maverick is the right resolution. After all, this is a regression from a previous release. (It was working in 8.0.4LTS so I'm assuming it was working up through 9.10 as well?)

[Herbert V. Riedel (hvr)]

well, waiting for it to be fixed in lucid didn't play out well either... (it was already broken in karmic) ;-)

[Thawn (webmaster-korten-privat)]

As far as I understood, the problem is, that fixing this bug would require the addition of new packages which have not been tested with lucid, yet and this would be a violation of the release procedure.

IMHO especially for a LTS version just breaking an important server feature (sharing printers) is important enough to make an exception and introduce these packages after the release.

What would be the "official" procedure for doing this?

[Jouke (digigram)]

even a ppa solution would be do it for me. I just do not know how to
repackage libdns and what version than is needed to get this to work without
breaking anything else. Anyone?

2010/5/28 Thawn <email address hidden>

> As far as I understood, the problem is, that fixing this bug would require
> the addition of new packages which have not been tested with lucid, yet and
> this would be a violation of the release procedure.
>
> IMHO especially for a LTS version just breaking an important server feature
> (sharing printers) is important enough to make an exception and introduce
> these packages after the release.
>
> What would be the "official" procedure for doing this?
>
> --
> CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting
> https://bugs.launchpad.net/bugs/465916
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Jouke Postma

[Matt Wynne (matt-mattwynne)]

Could someone post a step-by-step workaround for this?

[Thawn (webmaster-korten-privat)]

Matt: See my posts #3 and #6 for Mac snow leopard and leopard respectively
if you need more help, please ask more specifically.

[Zerocool3001 (timfall)]

Actually CUPS discover is turned on in most Leopard and Snow Leopard installations. More importantly it does not discover printers, so these fixes won't help.

[Matt Wynne (matt-mattwynne)]

Thawn thanks for your suggestions. What I'm looking for is the manual steps to patch / fix the server, rather than the clients.

[Thawn (webmaster-korten-privat)]

Matt: Sorry, I misunderstood.
Zerocool: I have to disagree, following the steps in my comments #3 and #6 fixes the issue for mac clients (it has done so for me and several other users). This is because it enables PRINTER discovery via cups which afaik is disabled by default on mac machines (at least on snow leopard and leopard). Please try the steps I suggested and tell me if that works for you.

[Jouke (digigram)]

As I understand a real server work around requires different software
versions (older cups or newer libdns?).

A manual work around would involve placing .service files for each
printer in the /etc/avahi/services/ folder. It seems challenging to
write the content of the file though. There are few working examples
on the net. This post may get someone started:
http://lists.freedesktop.org/archives/avahi/2007-April/001039.html

anyone with more insight, please let me know. Or if you are really a
guru in this area, would it be possible to write a script that
generates the .service files?

last idea, but I haven't tried it: netatalk can broadcast printers
using apple talk protocol. But I am not sure if that is still enabled
by default on the new macs.

2010/6/10 Thawn <email address hidden>:
> Matt: Sorry, I misunderstood.
> Zerocool: I have to disagree, following the steps in my comments #3 and #6 fixes the issue for mac clients (it has done so for me and several other users). This is because it enables PRINTER discovery via cups which afaik is disabled by default on mac machines (at least on snow leopard and leopard). Please try the steps I suggested and tell me if that works for you.
>
> --
> CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting
> https://bugs.launchpad.net/bugs/465916
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Jouke Postma

[Zerocool3001 (timfall)]

You're right about needing different packages (which is presumably why this bug has gone largely dead). The .service files however, are just descriptions of the what is being served, they don't initiate the serving itself. Since Avahi does not currently implement the API's that CUPS 1.4 uses to call libdns, it cannot properly serve our CUPS printers.

It seems like the only fix at this point would be to find a libdns package that supports the needed API's and then have CUPS statically linked to it, or to compile CUPS 1.4 with code from CUPS 1.3 that uses the old API's that Avahi can handle (see Till's post).

Thawn: I've tried using CUPS discovery on two Macs, both of which had it turned on by default. Neither is able to see a CUPS shared printer.

[Thawn (webmaster-korten-privat)]

Zerocool: Does printing work via cups with other linux clients on that server? What Mac OS version are you using? how did you enable CUPS discovery?

here is the relevant section from my CUPS configuration that works under Snow leopard and leopard clients with an ubuntu 10.4 printserver:

# Show shared printers on the local network.
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseRemoteProtocols cups # adding this line fixed the issue for me

[Lorenz Bort (lbort)]

Hi there!

I just want to confirm that adding this line fixed the issue for me, (Leopard 10.5.8 client, ubuntu 9.10 Server, which has been updated to 10.04 and is still working). The Printers show up in the "add Printer" dialog of OSX and I needed no configuration at all (no IP adress of the printserver or anything like that). I'm not 100% sure, but I think that I used this printer with an snow-leopard mac once and it worked, too.

Hope this information helps.

Lorenz

PS: I really don't understand why CUPS printer-sharing is not enabled by default and has to be enabled manually in a config file. This is definetly not what normal macusers do.

[Matt Wynne (matt-mattwynne)]

I'm using the client workaround and having trouble with it. Periodically the printer just disappears from the printers list on the Mac, and the only way to get it back is a reboot (of the Mac). I've tried restarting CUPS on the Mac but it doesn't seem to make a difference.

I appreciate that's not got much to do with this bug, but I just wanted to flag up that the workaround is far from perfect, and add some more support for getting a server-side solution into Ubuntu.

[AprilHare (hal-sulphur)]

Bug confirmed here.
Easiest way to test: http://localhost:631/ is browsable, http://myserver.local:631/ is not.
It affects configuring Windows machines using Bonjour services too (actually the nicer way to set up printing services under Windows, at least when zeroconf works).
Is there a PPA yet with the packages (libdns etc) needed? Running lucid..

[Matt Wynne (matt-mattwynne)]

Note on the workaround, if you find your printer drops out of the list on the Mac client, typing this at the terminal on the client helped for me:

    cupsctl BrowseRemoteProtocols=cups

Found from http://lists.apple.com/archives/printing/2007/Nov/msg00017.html

[Noel J. Bergman (noeljb)]

Mark Shuttleworth wrote on 2010-03-19: #25
> On 19/03/10 09:50, Till Kamppeter wrote:
> > Mark, the problem is that we are after Feature Freeze, so we cannot add
> > new packages any more. Or should we do a FF exception here?
> If it's there, and works, and would fix this bug without other
> side-effects, yes we should ask for that.

Today is August 17 -- 5 months after Mark suggested a Feature Freeze exception. It is still broken not only in Lucid. but also in Maverick.

What is the holdup and ETA?

[Edmund Ronald (edmundronald)]

Using VMWare on Snow Leopard, I can make Ubuntu 10.04 discover Snow Leopard printers, and Snow Leopard discover Ubuntu printers, but I cannot make one Ubuntu instance discover the printers of another instance.

Printing should just work; this bug is ugly. Typing in ip numbers for printers is not acceptable. Maybe downgrading to CUPS 1.3 might be a viable user workaround that requires little tech knowledge?

Edmund

[Rached Blili (striker-dread)]

Any word at all on when this will be fixed? This bug has been sitting here for a very long time.

[Edmund Ronald (edmundronald)]

I've managed to make my Ubuntu drivers visible from Windows by writing my own service file, however the issue is complex because one needs to decide whether to use a Windows driver or use the Cups filter chain to render the print - I'm not a guru so I simply don't know how to write correct service files, I suspect the only way to get them is from a functioning Bonjour implementation.

Edmund

[Lorenz Bort (lbort)]

Hi again,

I haven't upgraded my machine to 10.10 so I still run lucid with this bug and the workaround via CUPS but maverick seems to be still affected.

I think this Bug is a major Problem of CUPS, avahi and Apple (who owns cups?) and should really be fixed, at least in the next release. As stated above by someone, printing should "just work" and this is not the case at the moment... In my opinion this should be near the top of the avahi-priority list and CUPS should work on it as well.

[Zerocool3001 (timfall)]

Thawn: To respond to your question from some time ago (post #40), the default configuration file for Snow Leopard (which I am using) contains the line

BrowseLocalProtocols CUPS dnssd

My guess is that the local instance of dnssd picks up shared printers on the network and passes them to CUPS. It may be that adding the BrowseRemoteProtocols line bypasses this method and instead checks the network directly for CUPS shared printers.

However this solution still requires editing a configuration file on the client side, something most users will not want to do. While it may work in the meantime, it would be a problem for users to do this whenever they wanted to connect to a printer shared from an Ubuntu server.

Lorenz: The problem here (and the solution) lies within the Avahi implementation. It hasn't kept up with the changes to the CUPS library in 1.4. Likely the only solution here is update the Avahi package to use the new API's. However, seeing as there has been no action on this bug, I don't know that it will be fixed anytime soon.

[Jouke (digigram)]

Zerocool3001:

would a ppa for the avahi-daemon with the latest version 0.6.28 do the trick
for all?

2010/11/18 Zerocool3001 <email address hidden>

> Thawn: To respond to your question from some time ago (post #40), the
> default configuration file for Snow Leopard (which I am using) contains
> the line
>
> BrowseLocalProtocols CUPS dnssd
>
> My guess is that the local instance of dnssd picks up shared printers on
> the network and passes them to CUPS. It may be that adding the
> BrowseRemoteProtocols line bypasses this method and instead checks the
> network directly for CUPS shared printers.
>
> However this solution still requires editing a configuration file on the
> client side, something most users will not want to do. While it may work
> in the meantime, it would be a problem for users to do this whenever
> they wanted to connect to a printer shared from an Ubuntu server.
>
> Lorenz: The problem here (and the solution) lies within the Avahi
> implementation. It hasn't kept up with the changes to the CUPS library
> in 1.4. Likely the only solution here is update the Avahi package to use
> the new API's. However, seeing as there has been no action on this bug,
> I don't know that it will be fixed anytime soon.
>
> --
> CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting
> https://bugs.launchpad.net/bugs/465916
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Jouke Postma

[Zerocool3001 (timfall)]

Jouke: According to the bug report filed with Avahi (http://www.avahi.org/ticket/303), the dns-ds.h currently in the Avahi package does not use the API's for CUPS 1.4 (the details are on the avahi bug report). The dns-sd.h included in Mac OS X seems to use these correct API's and functions with CUPS 1.4.

It seems that the simple solution (as the bug maintainer suggests) would be to include the solution from Apple's dns-sd.h. However, looking at the comments on that bug shows that people don't agree with this solution (for what appears to be a dislike of Apple). Until dns-sd.h uses the API's in CUPS 1.4 (and to be used in future versions of CUPS), Apple's Bonjour would seem to be the only dnssd implementation that will work with CUPS.

[Jouke (digigram)]

Thanks, I finally get it.

2010/11/18 Zerocool3001 <email address hidden>

> Jouke: According to the bug report filed with Avahi
> (http://www.avahi.org/ticket/303), the dns-ds.h currently in the Avahi
> package does not use the API's for CUPS 1.4 (the details are on the
> avahi bug report). The dns-sd.h included in Mac OS X seems to use these
> correct API's and functions with CUPS 1.4.
>
> It seems that the simple solution (as the bug maintainer suggests) would
> be to include the solution from Apple's dns-sd.h. However, looking at
> the comments on that bug shows that people don't agree with this
> solution (for what appears to be a dislike of Apple). Until dns-sd.h
> uses the API's in CUPS 1.4 (and to be used in future versions of CUPS),
> Apple's Bonjour would seem to be the only dnssd implementation that will
> work with CUPS.
>
> --
> CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting
> https://bugs.launchpad.net/bugs/465916
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Jouke Postma

[Lorenz Bort (lbort)]

Thanks... I was aware of some of the problems, but your statement summed it up quite well. So let's hope that avahi solves this issue in the future....

[Jesse Dhillon (jesse-deva0)]

I'd like to add another reason to get this done, if it would add more motivation to get this through: Apple AirPrint is a DNS-SD service, and you need to have Avahi advertising print services to get your printer recognized as capable of AirPrint.

[Kim Robertson (kimr)]

When looking for patches I came across some on openSUSE.
They seem to use Avahi directly. Would that help not to cause issues with the release policy?
These might be completely off-base but might be of some help.

https://build.opensuse.org/package/files?package=cups-backend-dnssd&project=openSUSE%3AFactory%3AContrib

Specifically
cups-avahi.patch
cups-backend-dnssd.changes
cups-backend-dnssd.spec

[Kim Robertson (kimr)]

I also missed:
cups-dnssd-deviceid.patch

As noted in the .spec file for cups-backend-dnssd:

# Additional patches to activate DNS-SD and Avahi support
Patch900: cups-avahi.patch
Patch901: cups-dnssd-deviceid.patch

[Till Kamppeter (till-kamppeter)]

Kim, like our patches these patches only add DNS-SD printer/print server discovery via the dnssd backend. They do not add functionality with which the local CUPS daemon gets a DNS-SD server for remote clients.

But thank you anyway for looking this up.

Perhaps the cups-dnssd-deviceid.patch could be useful for us though, to improve reported device IDs.

[Till Kamppeter (till-kamppeter)]

According to the CUPS development roadmap

http://www.cups.org/roadmap.php?VERSION=1.5

the CUPS 1.5.x series will support Bonjour via Avahi.

Any tests of 1.5.x development code from SVN or even patches to backport this functionality to 1.4.x are welcome.

[Zerocool3001 (timfall)]

I'm a little confused. Does CUPS 1.4 (or 1.3) support Bonjour via Avahi? It was my understanding that Avahi was simply an open source implementation of the dns-sd protocol which Apple calls Bonjour. If this is the case wouldn't this mean Avahi will not function with CUPS until Avahi uses the new protocols and this problem would continue to exist in 1.5?

[Till Kamppeter (till-kamppeter)]

Avahi does not offer the complete API of Apple's Bonjour. So one cannot compile the DNS-SD code of upstream CUPS with Avahi, because there are function calls which do not exist in Avahi.This problem is only present in CUPS 1.4.x. CUPS 1.3.x supported Avahi, and 1.5.x will do so, too.

[Zerocool3001 (timfall)]

That's what I thought. However, since Avahi is not using the correct API's, wouldn't this problem continue to exist in CUPS 1.5 or is is there a planned work around?

The reason I ask is because it seems to me that this problem wont be solved until Avahi makes use of the correct API's.

[Till Kamppeter (till-kamppeter)]

CUPS 1.5.x will work around the deficiencies of the Avahi API. It will provide the DNS-SD functionality using only the API of Avahi. So we will only need to wait for CUPS 1.5.x if no one backports code of 1.5.x into 1.4.x.

[Till Kamppeter (till-kamppeter)]

Committed patch for full Avahi support for CUPS to the Debian BZR repository of CUPS. The fix will appear in the next Natty package of CUPS then.

[Mark Shuttleworth (sabdfl)]

 \o/ great work Till :-)

[Launchpad Janitor (janitor)]

This bug was fixed in the package cups - 1.4.5-1ubuntu1

---------------
cups (1.4.5-1ubuntu1) natty; urgency=low

  [ Till Kamppeter ]
  * debian/patches/cups-avahi.dpatch: Added patch from Tim Waugh from Red Hat
    to implement full Avahi support, not only for printer discovery by the
    "dnssd" backend but also for print queue broadcasting and browsing by the
    scheduler (CUPS daemon). Fixes LP: #465916.
  * debian/patches/dnssd-avahi.dpatch: Removed, is part of new
    cups-avahi.dpatch.
  * debian/patches/quiesce-bonjour-warning.dpatch: Removed, not needed any
    more with the new cups-avahi.dpatch.
  * debian/patches/usb-backend-no-segfault-on-bad-device-id.dpatch: Assure
    that the device ID string read from a USB device can never be a mess: Try
    other byte order for device ID string length also if length is too small,
    empty the read device ID string if there is an IOCTL failure, reject ID
    strings with unprintable characters, clean white space in the ID string,
    and finally accept the empty ID string as an unknown device. This
    overcomes the problem that USB-to-Parallel adapter cables do not
    report back a usable ID string. With these changes it is at least possible
    to use one adapter cable per computer if the cables do not report unique
    serial numbers via libusb and any number of adapter cables if they do
    report serial numbers via libusb. Real USB printers can always be used,
    also if there are other printers connected with an adapter cable
    (LP: #468701, LP: #564917).

  [ Martin Pitt ]
  * debian/local/apparmor-profile: Explicitly deny access to ttyUSB* to
    silence noise. This is presumably an extra control channel for some USB
    printers, but cupsd can't use it anyway. (LP: #692892)
 -- Till Kamppeter <email address hidden> Sun, 26 Dec 2010 18:07:33 +0100

[Till Kamppeter (till-kamppeter)]

Please update to cups 1.4.5-1ubuntu4. In the previous versions the CUPS daemon is crashing with segmentation faults a lot and also does not work at all if the Avahi daemon is not running, due to bugs in the new Avahi patch. With the mentioned version I succeeded to fix these bugs and the CUPS daemon has the expected behavior now.

[daqron (daqron)]

There is no cups version 1.4.5-1ubuntu4 in the repos. Most current version available is 1.4.3-ubuntu1.3. I tried installing the newer version from http://www.cups.org/software.php, and was able to install it, but after a reboot if I browse to localhost:631 it still shows version 1.4.3 and so does my package manager. Help??

[Till Kamppeter (till-kamppeter)]

daqron, you are probably using a released version of Ubuntu, Lucid or Maverick. The version 1.4.5-1ubuntu4 is in the repositories of Natty, the Ubuntu version which will get released in April this year. To test the new CUPS version, download a daily live CD of Natty (boot it, but do not install it as it is not yet ready for production use) and see whether you get the desired behavior in the Natty live session. Do not forget to activate the sharing of your local printers and/or accepting remote shared printers in System -> Administration -> Printing and there under Server -> Settings.

Note also that the CUPS 1.4.5 from cups.org does not have Avahi-based DNS-SD support. We have added the support with a patch.

Note also that the CUPS 1.4.5 which you have compiled from source is installed into subdirectories of /usr/local/ by default and so does not overwrite the CUPS of Ubuntu. You must explicitly uninstall the Ubuntu-provided CUPS to make sure that the source-compiled one gets used.

[Edmund Ronald (edmundronald)]

Till,

 I am working with Robert (color management for Gutenprint) and would
like to test this patch, together with a really recent version of
Gutenprint. Which version of Gutenprint is in the dailies from Natty?
My build/hack skills are limited, I'm a domain expert -

Edmund

On Wed, Jan 5, 2011 at 8:39 AM, Till Kamppeter
<email address hidden> wrote:
> daqron, you are probably using a released version of Ubuntu, Lucid or
> Maverick. The version 1.4.5-1ubuntu4 is in the repositories of Natty,
> the Ubuntu version which will get released in April this year. To test
> the new CUPS version, download a daily live CD of Natty (boot it, but do
> not install it as it is not yet ready for production use) and see
> whether you get the desired behavior in the Natty live session. Do not
> forget to activate the sharing of your local printers and/or accepting
> remote shared printers in System -> Administration -> Printing and there
> under Server -> Settings.
>
> Note also that the CUPS 1.4.5 from cups.org does not have Avahi-based
> DNS-SD support. We have added the support with a patch.
>
> Note also that the CUPS 1.4.5 which you have compiled from source is
> installed into subdirectories of /usr/local/ by default and so does not
> overwrite the CUPS of Ubuntu. You must explicitly uninstall the Ubuntu-
> provided CUPS to make sure that the source-compiled one gets used.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/465916
>
> Title:
>  CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting
>
> Status in Avahi:
>  New
> Status in “cups” package in Ubuntu:
>  Fix Released
>
> Bug description:
>  Binary package hint: cups
>
> I've enabled advertising of local printers in a recent upgrade to Karmic. The config file has these salient lines:
>
> Browsing On
> BrowseOrder allow,deny
> BrowseAllow all
> BrowseRemoteProtocols cups
> BrowseAddress @LOCAL
> BrowseLocalProtocols cups dnssd
>
> But CUPS still doesn't advertise using DNS-SD. (I can't find the printers with a Mac OS X v10.6 client, and I also checked by running avahi-browse locally.) I turned the log level to debug2 and didn't find any indication that DNS-SD was being used. (In particular, I expected "dnssdRegisterPrinter" to be logged, as reflected by line 2666 of dirsvc.c in the CUPS source.) Suspiciously, I noticed this line in the log file:
>
> d [30/Oct/2009:14:35:13 -0700] [CGI] Starting "{HAVE_DNSSD?" at 2802, result=0...
> d [30/Oct/2009:14:35:13 -0700] [CGI] Skip first part...
>
> I don't exactly know what's going on here, but is it possible that CUPS was for some reason compiled with the HAVE_DNSSD flag off?
>
> Further evidence: If I click "Advanced" on the "Administration" page, the protocols under "Share printers connected to this system" are CUPS, LDAP, and SLP. No DNS-SD.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/avahi/+bug/465916/+subscribe
>

[Till Kamppeter (till-kamppeter)]

The previous comment (#70) was not intended to be posted on this bug report. Please disregard it.

[daqron (daqron)]

Thanks Till! That all seems like a bit much just to get this feature working, at least for my present situation where the network printing isn't critical. It's disappointing that this feature doesn't work out of the box, but considering how much easier CUPS has made printing in Linux in general I guess I shouldn't complain too much.

[Jouke (digigram)]

Great work! Are there any plans to backport the patch to 10.04, given it's
long term support? I would prefer to keep my server on lts instead of the
usually more buggy in between releases.

2011/1/5 daqron <email address hidden>

> Thanks Till! That all seems like a bit much just to get this feature
> working, at least for my present situation where the network printing
> isn't critical. It's disappointing that this feature doesn't work out of
> the box, but considering how much easier CUPS has made printing in Linux
> in general I guess I shouldn't complain too much.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/465916
>
> Title:
> CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting
>

--
Jouke Postma

[Lorenz Bort (lbort)]

interesting question Jouke has, seconded!

otherwise I'll wait till the release of Natty and upgrade, my machine is not really a critical one, I stopped at 10.04 just because I didn't find the time to upgrade to 10.10 and didn't miss any feature. This one could change that ;)

[Rached Blili (striker-dread)]

Thirded. I would rather have this fix backported, especially since it's a patch.

[Mark Levitt (mark-marklevitt)]

I agree this should be backported to 10.04 because this had worked in 8.04. It's a regression from a previous release and should be fixed in 10.04.

[Arie Skliarouk (skliarie)]

Same problem on ubuntu 11.10 (oneiric). Freshly installed printer does not appear on a neighbor machines. Had to use an 11.04-based machine to share the printer on the network.

[Till Kamppeter (till-kamppeter)]

Oneiric has Avahi broadcasting functionality, like Natty. Please check whether the Avahi daemon is running and start it if not. If the Avahi daemon is taking 100% CPU, restart it. Make sure that you have turned on printer sharing and that the shared bit for each print queue which you want to use from remote clients is set.

[Arie Skliarouk (skliarie)]

Avahi is running and does not take 100% CPU:

root@ubuntu2:~# ps awux | grep avahi
root@ubuntu2:~# ps awux | grep avahi
avahi 739 0.0 0.0 32396 1944 ? S Dec13 0:00 avahi-daemon: running [ubuntu2.local]
avahi 740 0.0 0.0 32132 468 ? S Dec13 0:00 avahi-daemon: chroot helper
root 1200 0.0 0.0 9244 904 pts/0 S+ 05:58 0:00 grep --color=auto avahi
root@ubuntu2:~#

The "Share printers connected to this system" is checked. Protocols CUPS and DNS-SD.

What is the "shared bit for each print queue", and where do I set it up?

BTW, in the error log I saw the following error - is it related?
E [13/Dec/2011:21:18:58 +0200] Failed to update TXT record for HP_LaserJet_CM1415fn @ ubuntu2: -2

tcpdump on a different machine shows that cups on the oneiric (11.10) does not send the ipp broadcasts, whereas the natty (11.04) does.
05:53:51.444383 IP cmdesk09.local.ipp > 192.168.11.255.ipp: UDP, length 128

When debug mode on 11.10 is enabled, it looks like the broadcasts are sent (the lines repeat every 62 seconds):
D [14/Dec/2011:05:55:44 +0200] cupsdNetIFUpdate: "eth0" = 192.168.11.121:631

Notable, that at my home, cups print sharing on two computers with Ubuntu 11.10 works properly.

[Till Kamppeter (till-kamppeter)]

The "Shared bit" is in the configuration of each print queue. In system-config-printer, right click the printer's icon, click on "Shared" in the pop-up menu so that it gets a check mark.

[John Rose (johnaaronrose)]

I now have this problem on a 32 bit Precise PC. The printer is Shared. I have a feeling that a package with name containing dnssd was updated recently and it has been occurring since then. Please let me know what additional information that I should provide.

[John Rose (johnaaronrose)]

Error Log attached for Brother Hl-DN5250 printer

[John Rose (johnaaronrose)]

This bug appears to be back on Trusty, with a Samsung laser printer attached to my router.

[John Rose (johnaaronrose)]

PS The standard Add Printer dialog does not find the Samsung networked pnte.