From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: I have a Lexmark N4000e network print server connected to a Lexmark E330 laser. I am using a FC3 box as the spooler/server for that printer using cups. If I print to the N4000e using IPP, the printer will for the most part work OK but intermittently prints out error pages. I switched from IPP to raw socket (port 9100) to communicate between FC3 and the N4000e and the problem goes away -- everything then works 100% OK. If I then switch back to IPP the problem comes back. Hence I believe that there is some sort of bug in the way cups talks IPP to the N4000e. (In all tests the print jobs originate from WinXP boxes.) The PCL XL errors reported by the printer are of various types but are mostly like: PCL XL error Subsystem: KERNEL Error: Unspecified Operator: SetFont Position: 1929 PCL XL error Subsystem: KERNEL Error: IllegalTag Operator: 0x25 Position: 3408 These errors are printed as I show them on an otherwise blank page. I believe the errors are generated in the printer, not the N4000e. During my tests I was able to reliably cause the exact same error by repeatedly printing the same report. The error and position (as shown above) were the same each time. The report would print page 1 and page 2 and then the PCL XL error page and then stop (it was supposed to be 9 pages). I have a second printer, another E330, connected via direct parallel to the same linux box and if I printed the report to it, it worked fine. Therefore, the problem was definitely not the fault of the printer or the driver. Instead of the default E330 PCL driver, I tested with the E330 PS driver and instead of the PCL XL error on page 3, it would print a good page 3 and then stop (and not print pages 4-9 nor any error pages). I also did as Lexmark (and google hits) suggest and tried setting the PCL options in the XP print driver to "Auto" or "GL/2" or "raster". The problem remained or got worse (faulty output) on all settings except "XL". Cups reported nothing amiss in the log files, even with debugging turned on. It's almost like cups would send some IPP data and then stop midstream or the N4000e was running out of buffer and dropping data. Version-Release number of selected component (if applicable): cups-1.1.22-0.rc1.8.5 How reproducible: Sometimes Steps to Reproduce: 1. setup cups to print to N4000e using IPP 2. print a job from a WinXP box into cups 3. Actual Results: Sometimes it would print a blank page with a PCL XL error on it. Expected Results: No PCL XL error. The page printed should have been the proper printed page. Additional info:
Darn, why does bugzilla sometimes not wrap the description text? Sorry about that folks.
Thanks for your report. I'll need some more information from you: 1. Please could you attach the output of 'printconf-tui --Xexport'? This contains the configuration for the printer (as long as you used system-config-printer to set up the queue). 2. I'd like to see all of the TCP traffic between the CUPS print server and the N4000e print server, while that particular job is being spooled. You can use this command (as root) to obtain that: tcpdump -s 0 -U -w traffic.pcap host 192.168.1.1 with 192.168.1.1 replaced by the IP address or hostname of the N4000e print server.
1. I did not use system-config-printer to set up the queue. I'm an old school kind of guy. 2. It may be a while before I can get the tcpdump as the box is about 100km away and I need to be present to see if the PCL XL error occurs. It also might be tough to reproduce the error on demand. I got really lucky the other day when I was reliably able to make a certain report error out -- normally it's much more intermittent. I suppose there's a 50% chance the bug is in the N4000e and not linux, but at least this entry will help anyone else that runs into this. My guess is the traffic to the N4000e will look normal -- but we'll see. I'll report back once I have the tcpdump.
Please attach the PPD for the queue (/etc/cups/ppd/queuename.ppd). Also: if you can get a reliable reproducer, please set up a queue to print to a file using that PPD, so we can see what *ought* to get sent. Then we can something to compare the TCP traffic to.
There are no files in /etc/cups/ppd. I think this is because it's a "raw" queue? I'm fairly new to cups and don't have all the concepts figured out yet. How would I set it up to print to a file?
Ah, yes, it is a raw queue then. Unfortunately I think there is a bug in CUPS regarding printing to a file on a raw queue. :-/
OK, I'll still do the tcpdump stuff next time I am there and report back (might be a few weeks).
Hi again, I finally was out onsite and was able to test again, this time with tcpdump running. Unfortunately, I didn't figure out till later that I needed -i eth1 on tcpdump. I did make the bug occur once, but that was before the -i so I didn't capture it. I had a hard time reproducing the bug as I couldn't remember the exact sequence of events to make their custom app cause the bug. I am waiting now for better instructions on their app and will test again next time. However, I did see some weird behaviour that is probably related. In one function in their app, you can print schedules and if I print one that's big, it always failed in a strange way. The printer LED would flash like it was going to print, then the power LED would flash then the printing LED once more then nothing -- no print, no error, no LEDs. If I then send a smaller schedule, it prints fine. All this is using IPP. If I switch to socket: then it all works 100% ok. It would appear that the bug is print job size dependent, or maybe per page size. Above a certain size and it prints nothing. I have a funny feeling hitting the bug at a certain threshold causes the PCL XL page to print. I just need to find out how to do it again. Attachment will follow.
Created attachment 117732 [details] tcpdump text output of all traffic to print server This tcpdump is of tons of tests I did trying to make the bug occur. Many of the prints around the 03:5x mark (I think?) were ones that hit the new "didn't print anything" version of the bug. I know it's a lot of output. Next time when I can better reproduce the PCL XL bug I'll take a snapshot of just that.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Fedora Core 3 is not maintained anymore. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release, please reopen this bug and assign it to the corresponding Fedora version.