Bugzilla – Bug 1084799
cups-browsed not working properly after resume (from suspend/hibernate) in a different network environment
Last modified: 2018-03-19 10:21: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)
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 -----------------
BrowseAllow 192.168.55.1 <---- This is the IP of my server at home
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.
Added an issue on github:
Only two side notes FYI:
I wonder why you have both
because I think when you have "BrowsePoll 192.168.55.1"
you do not need additionally "BrowseAllow 192.168.55.1"
because with "BrowsePoll 192.168.55.1" cups-browsed
actively polls the cupsd on 192.168.55.1 for its queues
while in contrast "BrowseAllow 192.168.55.1" means that
cups-browsed would accept incoming queue announcements
from the cupsd on 192.168.55.1.
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 10.160.0.103 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.
(In reply to Johannes Meixner from comment #3)
> Only two side notes FYI:
Thanks for this :)
> I wonder why you have both
> BrowseAllow 192.168.55.1
> BrowsePoll 192.168.55.1
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)
> 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.
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...)
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).