Bug 1084799

Summary: cups-browsed not working properly after resume (from suspend/hibernate) in a different network environment
Product: [openSUSE] openSUSE Tumbleweed Reporter: Peter Sütterlin <P.Suetterlin>
Component: PrintingAssignee: Johannes Meixner <jsmeix>
Status: RESOLVED UPSTREAM QA Contact: Johannes Meixner <jsmeix>
Severity: Enhancement    
Priority: P5 - None    
Version: Current   
Target Milestone: ---   
Hardware: All   
OS: openSUSE Factory   
URL: https://wiki.linuxfoundation.org/openprinting/cups-filters
Found By: Community User Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Peter Sütterlin 2018-03-11 08:00:01 UTC
I always only resume my laptop when switching between home and office, so it normally gets a new IP address during resume.

At home, I have a small server with a connected printer (running Leap 42.3/cups) that is shared in the local network.  cups is set to poll this server.

If I resume at home, I can see the printer:
woodstock:~% lpstat -a
ml2850 accepting requests since Sun 11 Mar 2018 08:24:14 CET

(the timestamp is the time when I resumed the laptop).
I can print to the printer, and it will show the job in the queue:

woodstock:~% lpq -Pml2850
ml2850 is ready and printing
Rank    Owner   Job     File(s)                         Total Size
active  pit     100     2014_all.pdf                    4251648 bytes

But the job does not get printed.

In /var/log/cups/error_log on the laptop I see:
E [11/Mar/2018:08:24:14 +0100] [Client 7] Returning IPP client-error-bad-request for CUPS-Add-Modify-Printer (ipp://localhost:631/printers/ml2850) from localhost
E [11/Mar/2018:08:33:43 +0100] [Job 100] No destination host name supplied by cups-browsed for printer \"ml2850\", is cups-browsed running?

cups-browsed *is* running:
woodstock:/var/log/cups # systemctl status cups-browsed
● cups-browsed.service - Make remote CUPS printers available locally
   Loaded: loaded (/usr/lib/systemd/system/cups-browsed.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2018-03-09 13:49:07 CET; 1 day 18h ago
 Main PID: 1053 (cups-browsed)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/cups-browsed.service
           └─1053 /usr/sbin/cups-browsed

If I restart cups-browsed, the job is deleted from the queue without being printed, but after that printing to this printer does work as expected.

---------  cups.browsed.conf  -----------------
BrowseRemoteProtocols DNSSD,CUPS
BrowseDeny All
BrowseAllow           <---- This is the IP of my server at home
BrowsePoll royac6.royac.iac.es
LocalQueueNamingRemoteCUPS RemoteName
Comment 1 Johannes Meixner 2018-03-12 09:14:21 UTC
I think it is a missing feature in cups-browsed
that it could somehow automatically adapt itself
to a changed network environment.

We (i.e. openSUSE) do not develop cups-browsed.
We only distribute it "as is" from upstream.

Accordingly such enhancement requests should be
better done directly at cups-browsed upstream, cf.

This way there is a direct communication between you
and the upstream authors, cf. "Background Information" at

Preferably post an URL to your upstream issue report
as reference here.
Comment 2 Peter Sütterlin 2018-03-12 09:39:51 UTC
Added an issue on github:
Comment 3 Johannes Meixner 2018-03-12 10:04:19 UTC
Only two side notes FYI:


I wonder why you have both


because I think when you have "BrowsePoll"
you do not need additionally "BrowseAllow"
because with "BrowsePoll" cups-browsed
actively polls the cupsd on for its queues
while in contrast "BrowseAllow" means that
cups-browsed would accept incoming queue announcements
from the cupsd on

At least for me when I have only this active line
in my /etc/cups/cups-browsed.conf I get the queues of
the CUPS server on my client system where
cups-browsed runs (and I can print to those remote queues).


cups-browsed automatically creates "volatile" local raw queues
that only forward print jobs to the autodetected remote queues
but those "volatile" local raw queues get also automatically removed
by cups-browsed when their matching remote queue is no longer available
(cf. "BrowseTimeout" in "man cups-browsed.conf") so that print jobs
that were submitted to such a "volatile" local queue would get
lost when cups-browsed removes the "volatile" local queue.

If that behaviour is not wanted normal local raw queues
that forward print jobs to remote queues should be set up.
Comment 4 Peter Sütterlin 2018-03-12 10:22:07 UTC
(In reply to Johannes Meixner from comment #3)
> Only two side notes FYI:

Thanks for this :)
> 1)
> I wonder why you have both
> BrowseAllow
> BrowsePoll

Mostly a leftover, IIRC I had first tried explicit Allows, but then switched to Poll (or the other way around?) when it didn't work as wanted....
I'll try again without the Allow.

(and if it really doesn't work, I'll probably try if-up.d or some systemd magic to restart it.  It's only a minor nuisance anyhow, I don't print too much)

> 2)
> cups-browsed automatically creates "volatile" local raw queues
> that only forward print jobs to the autodetected remote queues
> but those "volatile" local raw queues get also automatically removed
> by cups-browsed when their matching remote queue is no longer available

Yes, that behavior is fine for me.
Comment 5 Peter Sütterlin 2018-03-18 16:40:32 UTC
Just some feedback:
I removed the BrowseAllow lines, leaving only the Poll ones - and the problem seems gone!  At least I could directly print today after resuming at home.

I don't understand why (the two options should not collide - only the Allow is not really neccessary), but if it works...

(The reason behind the Allow was my issues with avahi, see boo#1079854.  I thought cups-browsed itself is finding the weird print servers, and had a Deny all, and only allowed the ones I wanted...)
Comment 6 Johannes Meixner 2018-03-19 10:21:01 UTC
Only an offhanded info from what I remember from the past:

In the past BrowsePoll (in particular with several remote servers)
worked more fail-safe for me because this way the client actively
polls each remote server for its queues and if one does not reply
(e.g. the company server when you are at home) it didn't matter
while in contrast BrowseAllow requires that queue announcements
that are sent by remote servers can successfully arrive
at the listening process at the client where various things
(e.g. firewall, subnets, DNS, whatever...) could get in the way.

Or in other words: With BrowsePoll the networking stuff
is actively initiated from the client (basically in the
same way as when the client submits a print job)
while in contrast with BrowseAllow the client is passive.

In this case it seems when things fail for BrowseAllow
it may even have side-effects on the BrowsePoll results
(but I did not analyze what exactly goes on here).