Bug 140761 - 2.6.9 kernel breaks ability to print to lpd print server
2.6.9 kernel breaks ability to print to lpd print server
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-24 13:46 EST by Aaron Metzger
Modified: 2015-01-04 17:13 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 01:29:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aaron Metzger 2004-11-24 13:46:34 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040803 Firefox/0.9.3

Description of problem:
This may be a cups problem not a kernel problem but changing kernel
version is the thing that breaks or fixes as follows.

Running Fedora Core 2 with all released updates applied.

With kernel versions 2.6.9-3 and 2.6.9-1, I can not longer print to an
lpd network printer (hp1300) which is sitting behind a NetGear PS113
print server.  Cups diagnostic indicates that it can't establish a
connection.  With this same kernel, I can print normally to an Epson
CX6400 printer sitting behind a Netgear PS121 lpd print server
(ethernet to USB).

With all else the same, booting with 2.5.8-1 kernel causes printing to
work normally.

Version-Release number of selected component (if applicable):
kernel-2.6.9-3

How reproducible:
Always

Steps to Reproduce:
1.Fedora 2 with 2.6.9 kernel
2.Setup CUPS queue for lpd printer behind Netgear PS113.
3.Try to print.  Job is submitted but cups can't communicate with
print server.
    

Expected Results:  Data to printer.

Additional info:
Comment 1 Aaron Metzger 2004-11-25 20:23:36 EST
Problem also exists in Fedora Core 3 with all released patches
applied.  Cups log is as follows: 

Started filter /usr/lib/cups/filter/foomatic-rip (PID 2513) for job 1.
I [25/Nov/2004:19:51:46 -0500] Started backend
/usr/lib/cups/backend/lpd (PID 2514) for job 1.
E [25/Nov/2004:19:54:56 -0500] [Job 1] Unable to connect to printer;
will retry in 30 seconds...: Connection timed out
E [25/Nov/2004:19:58:35 -0500] [Job 1] Unable to connect to printer;
will retry in 30 seconds...: Connection timed out
E [25/Nov/2004:20:02:14 -0500] [Job 1] Unable to connect to printer;
will retry in 30 seconds...: Connection timed out
E [25/Nov/2004:20:05:53 -0500] [Job 1] Unable to connect to printer;
will retry in 30 seconds...: Connection timed out
E [25/Nov/2004:20:09:32 -0500] [Job 1] Unable to connect to printer;
will retry in 30 seconds...: Connection timed out
E [25/Nov/2004:20:13:11 -0500] [Job 1] Unable to connect to printer;
will retry in 30 seconds...: Connection timed out
E [25/Nov/2004:20:16:49 -0500] [Job 1] Unable to connect to printer;
will retry in 30 seconds...: Connection timed out
E [25/Nov/2004:20:20:28 -0500] [Job 1] Unable to connect to printer;
will retry in 30 seconds...: Connection timed out
Comment 2 Aaron Metzger 2004-11-25 22:40:26 EST
First, sorry, there is a typo in the original posting.  The kernel
version in which printing works normally is 2.6.8-1.521 not 2.5.8.

Dug a little deeper into the problem.

An ethereal trace of the traffic between the host and the print server
indicates that cups initiates the connection using a privileged port
#1023.  The response back to port 1023 from the print server is
rejected with an ICMP destination unreachable.  Using
system-config-securitylevel to completely disable the firewall, causes
printing to occur normally.

Using the 2.6.8 kernel, the initial request from the host to the print
server is from an emphemeral port (#32782 in one experiment).  The
response from the print server makes it back to the host and printing
occurs normally without disabling the firewall.

Comment 3 David A. Cafaro 2005-01-27 19:19:30 EST
I would like to add that with iptables enabled for
kernel-2.6.10-1.9_FC2-SMP with cups-1.1.20-11.10 and
iptables-1.2.9-2.3.1 and trying to print over a network via LPD
services to a Netgear PS111W I experience the same problem.  This is a
wireless print server.  Windows XP computers experience no problems
printing at the same time.

In addition accessing the webinterface on the print server also fails.

If I have enabled the firewall in security level setting, yet turned
the rules off via the command line "/etc/init.d/iptables stop", then I
have partial access to the webinterface (the primary page loads, but
without the frames, but I can see the source of the page), but am
still unable to print.

With the firewall disabled via security level gui and a clean reboot,
everything works as expected.  
Comment 4 Peter Cheney 2005-03-01 00:51:29 EST
Could I please also add to this except my printer (Epson Stylus Colour
740) is direct connected via the parallel port.

Using kernel 2.6.9-1.6 everything was fine. Applied numerous updates
including kernel 2.6.10-1.12 and brought entire system up to date.

Printing stopped. At first I thought a cups update might be the cause
so I played around there. No luck. Then a new kernel 2.6.10-1.14 came
out a few days later so I thought OK lets' try that. No go. Error in
printing gui for lp0 was something like "unable to contact printer".
Printing via win2k from other partition on same PC was still working.

So I went back to the original kernel and all the print jobs spewed forth.

System is currently all up to date except for running the older kernel.
Comment 5 Dave Jones 2005-04-16 01:29:31 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

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