Bug 100913 - Severn/Shrike CUPS interop failure
Summary: Severn/Shrike CUPS interop failure
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: cups
Version: beta1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: CambridgeTarget
TreeView+ depends on / blocked
 
Reported: 2003-07-27 00:22 UTC by Need Real Name
Modified: 2007-04-18 16:56 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-08 16:30:41 UTC
Embargoed:


Attachments (Terms of Use)

Description Need Real Name 2003-07-27 00:22:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
I have an HP LJ3P printer connected to the parallel port on a machine running
RHL9 and CUPS.  This works fine.

I have also set up another RHL9 machine on my LAN to use CUPS, and to print to
the remote HP LJ3P printer on the first machine.  This also works fine.

When I try to configure a third PC running the Severn beta to access this same
HP LJ3P printer, things are no longer so fine.  

In the redhat-config-printer window on the severn PC, the remote printer shows
up under the "Browsed queues" tree, and the description of the printer matches
what I entered on the first PC to which the printer is connected.  However, I am
unable to set this queue up.  The edit, delete, default, sharing, delete, and
apply actions are all inactive.

When I force the issue by manually setting up a print queue using the same
parameters as I used to successfully set up access to the remote printer from
the second PC as described, any attempt to print a test page results in an Error
dialog box that says 

   There was a problem sending ASCII text test page to 'hp' queue:
   lpr: unable to print file: server-error-service-unavailable

Now here's the odd part: I had been running tcpdump on the severn box during
this whole time, and there was never any network traffic sent from the severn
box during this whole time.  The only traffic was the udp packets sent from the
machine with the printer to 255.255.255.255.ipp every 30 seconds.

Version-Release number of selected component (if applicable):
cups-1.1.19-8 (severn), 1.1.17.13.3 (shrike)

How reproducible:
Always

Steps to Reproduce:
1. Set up a LAN as described above.
2. Perform the steps described above.
3. Observe the results described above.
    

Actual Results:  I can print stuff locally or from another shrike machine, but
not from a severn box on the same LAN.

Expected Results:  I'd like to be able to print LAN-wide.

Additional info:

I've tried disabling all packet filtering, restarting all the cups daemons, and
all the other things that I could think of without any change.

Comment 1 Tim Waugh 2003-07-30 11:18:32 UTC
For the first part of your report:

There is no need to 'set the queue up': CUPS has detected the queue on the
remote machine and it is ready to use.  The 'Test' menu bar item should be
usable, for instance.  Browsed queues are immediately usable on the local machine.

For the error dialog part:

It sometimes takes a while for CUPS to become available after changes are
applied.  What happens if you try a test page from 'Test' on the menu bar?

Comment 2 Need Real Name 2003-07-30 12:07:57 UTC
The remote queue doesn't seem ready to use.  While visible, it's unusable. 
Trying to print a test page from 'Test' on the menu bar results in the same
'Error' dialog box saying that 'There was a problem sending CUPS test page to
'hp' queue: lpr: unable to print file: server-error-service-unavailable'.  This
error determination was made without any network traffic being sent to the
machine hosting the remote printer.

Another indication that the remote print queue isn't ready to use is that the
'Set as default' options (both in the 'Action' menu item, and in the mouse
button 3 menu) are greyed out.

Repeating the test after restarting both CUPS servers, disabling packet
filtering on both sides, and waiting for several ipp broadcasts to be received
from the machine hosting the remote printer makes no difference.

Comment 3 Tim Waugh 2003-07-30 12:39:47 UTC
'Set as default' will be greyed out normally.  But you should be able to print a
test page.

Please set LogLevel to debug2 in /etc/cups/cupsd.conf, restart cups, and try
again.  Then look in /var/log/cups/error_log for clues.

Comment 4 Need Real Name 2003-07-31 14:44:43 UTC
I shut down cupsd on both the shrike machine hosting the locally-attached
printer (papa) and on the severn machine from which I was trying to print a test
page (scrap).  I set Loglevel to 2 in both cupsd.conf files, truncated both
error_log files, restarted both cupsd servers, and tried printing two test
pages.  Both attempts failed as described previously.

While I see indications of a failure in the error_log file, it isn't obvious
what is causing the failure.  

The error_log file from the machine where I tried to print the test page is at
http://home.comcast.net/~kodis/cups/error_log.scrap

I've also made available a copy of the cupsd.conf file as cupsd.conf.scrap, and
the error log and configuration files from the machine to which the printer is
connected as error_log.papa and cupsd.conf.papa

Comment 5 Tim Waugh 2003-08-13 16:22:45 UTC
The error_log files don't show any print attempt -- in other words, I don't
think that the scheduler on the Severn machine has any knowledge of the print job.

Please try:

lpstat -s    <-- should list available print queues
lp -d hp /usr/share/printconf/tests/testpage.asc   <-- should try to print file

If the 'lp' command fails, please try:

strace lp -d hp /usr/share/printconf/tests/testpage.asc 2>log

and attach the log file.  Thanks.

Comment 6 Tim Waugh 2004-01-28 12:41:14 UTC
*ping*

Comment 7 Tim Waugh 2005-09-08 16:30:41 UTC
No feedback.


Note You need to log in before you can comment on or make changes to this bug.