Bug 1084799 - cups-browsed not working properly after resume (from suspend/hibernate) in a different network environment
cups-browsed not working properly after resume (from suspend/hibernate) in a ...
Status: RESOLVED UPSTREAM
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Printing
Current
All openSUSE Factory
: P5 - None : Enhancement (vote)
: ---
Assigned To: Johannes Meixner
Johannes Meixner
https://wiki.linuxfoundation.org/open...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-11 08:00 UTC by Peter Sütterlin
Modified: 2018-03-19 10:21 UTC (History)
0 users

See Also:
Found By: Community User
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 192.168.55.1           <---- This is the IP of my server at home
BrowseAllow 161.72.15.0/24
BrowsePoll royac6.royac.iac.es
BrowsePoll 192.168.55.1
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.
https://wiki.linuxfoundation.org/openprinting/cups-filters

This way there is a direct communication between you
and the upstream authors, cf. "Background Information" at
https://en.opensuse.org/SDB:How_to_Report_a_Printing_Issue

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:
https://github.com/OpenPrinting/cups-filters/issues/33
Comment 3 Johannes Meixner 2018-03-12 10:04:19 UTC
Only two side notes FYI:

1)

I wonder why you have both

BrowseAllow 192.168.55.1
BrowsePoll 192.168.55.1

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
-------------------------------------------------------------
BrowsePoll 10.160.0.103
-------------------------------------------------------------
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).

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
(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 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)

> 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).