Red Hat Bugzilla – Bug 134702
CUPS cannot access remote printer/cupd
Last modified: 2007-11-30 17:10:50 EST
Description of problem: Despite having being able to print CUPS test
pages on both remote printers immediately after configuration, all
subsequent attempts (the next day) to print or list remote printer
status with "lpstat -t" produce a "client-error-forbidden" status.
Reconfiguring the printers as LPD queues and enabling the cups-lpd
service allowed the remote printers to be used.
Version-Release number of selected component (if applicable):
cups-1.1.20-11.3 (on both the local and remote printer hosts)
How reproducible: This environment has printers connected to the
parallel ports of two hosts (a and b) running FC2 with
cups-1.1.20-11.3 and the cupsd service enabled. When host a is
configured to have a remote CUPS printer on host b (and vice-versa)
the initial printing of a CUPS Test page may work, but further
attempts to access the remote printer(s) will fail with the
"forbidden" error. Attempts to reconfigure the CUPS queues did not
clear the error. There is also a router/firewall between the two
hosts, and port 631 (IPP) is open - telnet from host a to port 631 on
host b works fine.
If the remote printers are reconfigured as LPD type queues, and the
cupd-lpd service enabled, remote printing work properly.
Steps to Reproduce: (see above)
Actual printers used here are an HP LaserJet 3 and an HP DeskJet
5550C. The errors encountered with the CUPS type queues were
symmetric (the same regardless of which printer was involved).
BTW, the system-config-printer script was used to perform all
(re)configuration operations. DMK
It sounds like you are having to take some action on host A (for
example) to get it to use the printer on host B. This should not be
necessary, other than to make sure that the firewall on host A allows
incoming UDP packets on port 631.
Can you check the firewall please, and make sure that UDP port 631 is
Actually, the client-error-forbidden failure is symmetric (i.e. it
also occurs when host B tries to access host A's IPP-shared printer).
I checked the firewall/router configuration between host A and host B
and, indeed, forwarding for port 631 is enabled for both UPD and TCP
packets travelling from host A to host B. Also, ALL tcp/udp ports are
open for host B traffic going to host A, hence an unlikely source for
the problem of host B printing on host A's printer.
Furthermore, the symmetric nature of the error and the fact that the
fw/router has port 631 is open in both directions for both udp and tcp
traffic suggests the problem lies elsewhere - perhaps in the cupsd
configuration. Since I used the system-config-printer script to
configure the both printers on both hosts, perhaps copies of the
resulting config files would be useful to your analysis. If so,
please advise which files you would like to see and I will forward
them directly or thru another attachment here.
The reason I asked about the firewall is this:
Having configured the local printer on host A, and the local printer
on host B, there should be nothing further to do.
But it sounds like you needed to do more, so something's up. Did you
configure each queue for sharing? If you right-click on the (local)
queue name in the system-config-printer application and select
'Sharing...', does it show that the queue is allowed to be used by the
Both printers were configured for sharing on their respective host systems, and
were reported as allowing access from all other systems. This is why the
problem seemed so perplexing.
I now suspect that the problems arose because I attempted to configure (using
the std system-config-printer script) the remote/CUPS printers on the client
hosts - a step that appears to be unnecessary when using CUPS. Relaizing this,
I do not think that the problem lies in the CUPS server or firewall, but rather
was caused by something that happened on the client host - perhaps as a result
of something I did within the system-config-printer dialog.
I regret that I cannot revisit this issue at this time, because the deployment
schedule required a "workaround" which I accomplished using a traditional
lpd-style configuration, which (still) works quite well.
Okay. I'll close this now then. If you have occasion to revisit this issue
please re-open it.