Description of problem: network printing unusable Version-Release number of selected component (if applicable): cups-1.3.7-2.fc9.i386 How reproducible: 95% failure rate Steps to Reproduce: 1. Configure a printer for AppSocket/HP JetDirect 2. Example Device URI: socket://172.21.1.16:9100 3. Print a test page Actual results: The print stream freezes, then gets corrupted. then prints hundreds of pages with one line of gibberish on each page. Expected results: A nice test page output. Additional info: Network printing works fine under Fedora 4 and works fine for Gutsy Gibbon. Our two Fedora 9 boxes both cannot print to either of two different model network printers. It appears to be a low level network flow problem. A really short job such as "date | lp" may work a few times in a row. Slightly longer jobs such as "lp /etc/passwd" rarely complete. The standard printer test page never completes.
Please try running the troubleshooter (System->Administration->Printing, then Help->Troubleshoot), and attach the resulting troubleshoot.txt file here. Thanks.
Created attachment 308577 [details] Result of printer troubleshooting process As usual the test page started printing hundreds of pages with a single line of gibberish at the top. I cancelled the print job "cancel 35" on Fedora 9, then I cancelled the job using the cancel button on the printer several times. These had no effect in stopping the flow of ruined pages until I rebooted my system. Yikes!
Created attachment 308796 [details] test.prn Attached: output of "gs -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -sDEVICE=pxlmono -r600x600 -sOutputFile=- - </usr/share/cups/data/testprint.ps >/tmp/test.prn" Please try printing the attachment this like: lp -dlexmark -oraw test.prn Does it give any different result? The difference is that this avoids using perl to post-process the output.
I tried printing test.prn in raw mode and got identical behavior with the hundreds of corrupted pages. I don't think that this is any kind of foomatic problem. It is something much more low level where the stream handshaking breaks down, blocks get dropped, and the printer loses track of what is formatting commands and what is data so it prints pure garbage. The reason that I think this is that sometimes really small jobs such as "date|lp" make it through correctly but sometimes they don't. Once a job fails, every job after that prints pure garbage until a reboot.
OK, let's look at the network traffic then. Please start a terminal window and become root (with 'su -'), and then run this command: tcpdump -s0 -U -w cups.pcap host 172.21.1.16 Then submit a job using 'date|lp'. Note whether it succeeds and name it appropriately using either: mv cups.pcap good.pcap or mv cups.pcap bad.pcap Repeat until you have both good and bad captures. Then please attach them both here. Thanks.
Forgot to say, once the job has completed, press Ctrl-C in the terminal window that is running tcpdump to stop it (sorry if this is obvious).
Created attachment 308932 [details] successful tcpdump Successful tcpdump of: echo " This printed correctly. This printed correctly. This printed correctly. This printed correctly. " | /usr/bin/lp
Created attachment 308933 [details] failed tcpdump tcpdump of failed print: echo " This printed correctly. This printed correctly. This printed correctly. This printed correctly. " | /usr/bin/lp Corrupted pages started printing and the job stayed in the lpq until I issued a cancel command.
This is a network problem. We are desperately trying to send packets to that system, but sometimes it is not seeing them or is receiving them incorrectly.
Ok, but every other machine on the network running RHEL4, RHEL 5, CentOS 5, Fedora 4, Ubuntu 7.10, Ubuntu 8.4, Windows XP and Windows Vista can print to these printers. Only the two Fedora 9 boxes cannot. What is so fragile about Fedora 9 networking that it cannot handle what everything else can handle just fine? Do we want this fragility to end up in RHEL 6?
Reassigning to kernel for further analysis.
There is something wrong with the network on those boxes. Does some other OS work on those same machines? You could try a Live CD for example. It looks like bad cables or something like that.
Hi Chuck There is no doubt that the network has problems. Sometimes other OSes take quite a while to print. However they *do* eventually print, unlike Fedora 9 which chokes. See comment #10 for a list of other OSes that do work, basically everything else. I cannot provide any more information from the Fedora 9 workstations. I reinstalled both of the Fedora 9 machines with CentOS 5 which does work. It isn't just printing that is fragile for Fedora 9. I was also having problems with curl and tomcat which CentOS 5 fixed. Printing I can live without. Basic networking functionality I cannot! Best, John
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.