Bug 1026753

Summary: CUPS fails to send job to Windows LPD service
Product: [Fedora] Fedora Reporter: Tim Waugh <twaugh>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: danofsatx, jpopelka, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1026613 Environment:
Last Closed: 2015-02-02 18:39:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1026613, 1026755    
Bug Blocks:    
Attachments:
Description Flags
LPD pcap with ML2540 Driver
none
Error log from LPD test
none
LPD pcap using PCL 4 LF driver
none
Error log from LPD test none

Description Tim Waugh 2013-11-05 11:19:00 UTC 
+++ This bug was initially created as a clone of Bug #1026613 +++

Description of problem:
Attempted to install two different printers to FC20 Beta (Fedora-20-Beta-x86_64-DVD.iso) using cups-bjnp to a Canon MP980 MFP, and both LPD and smb to a Samsung ML2540 laser printer shared from a Windows 8.1 system.

[...]

With LPD through Windows to the Samsung laser, cups again gives no indication of any errors, but the Windows Event Log states "The Line Printer Daemon (LPD) service received commands in an invalid format from 192.168.1.15 and refused the print job. This can occur if the Line Printer Remote (LPR) client is incompatible with the Windows LPD service and Request for Comments (RFC) 1179. Try printing using a different LPR client."

[...]

Version-Release number of selected component (if applicable):
cups 1.7.0
cups-bjnp 1.2.1
cups-libs 1.7.0
cups-pk-helper 0.2.5

How reproducible:
So far, I've only been able to test locally.

Steps to Reproduce:
1. Set up Canon printer on network, and Samsung laser printer shared via Windows 8.1 with both LPD service and anonymous smb access allowed.

2. Add the printers through the CUPS web interface at https://localhost:631 using bjnp, LPD, and smb access.

3. Submit a job to the printers.

Actual results:
Printers indicate they are receiving data, but print jobs are not completed.

Expected results:
Completed print jobs.

Additional info:
The Canon printer works in FC19 using the cups-bjnp package, and configured through the web interface as described above.
Comment 1 Tim Waugh 2013-11-05 12:53:03 UTC 
Cloned from bug #1026613. Let's concentrate on the LPD issue here.

It would be useful to see the TCP traffic, so we can see exactly where the fault lies.

Please run this command, as root, to capture it:

tcpdump -n -U -s0 -w lpd.pcap port 515

While that command is running, submit a small print job (such as the test page) to queue that uses LPR. When the job has finished/failed, use Ctrl+C to stop the tcpdump command.

Please attach the resulting lpd.pcap file here. Thanks.
Comment 2 Dan Mossor [danofsatx] 2013-11-07 03:22:27 UTC 
Created attachment 820851 [details]
LPD pcap with ML2540 Driver

First run with official Samsung ML2540 Driver.
Comment 3 Dan Mossor [danofsatx] 2013-11-07 03:24:39 UTC 
Created attachment 820852 [details]
Error log from LPD test

Error log during test run with ML2540 drivers.
Comment 4 Dan Mossor [danofsatx] 2013-11-07 03:43:37 UTC 
Created attachment 820855 [details]
LPD pcap using PCL 4 LF driver

PCAP of test using Generic PCL 4 LF Printer - CUPS+Gutenprint v5.2.9 (grayscale, 2-sided printing) driver.
Comment 5 Dan Mossor [danofsatx] 2013-11-07 03:44:36 UTC 
Created attachment 820856 [details]
Error log from LPD test

Error log from test using Generic PCL 4 LF Printer - CUPS+Gutenprint v5.2.9 (grayscale, 2-sided printing) driver.
Comment 6 Tim Waugh 2013-11-15 17:22:16 UTC 
Looking at the trace from comment #4:
CUPS sends "I'd like to print to 'queue'".
Windows says "Queue not accepting jobs".

CUPS is behaving correctly. There's really nothing for Windows to complain about:

02 71 75 65 75 65 0a
^  ^^^^^^^^^^^^^^  ^ LF
|         |
|         + 'queue'
|
+- receive print job

exactly like RFC 1179 says, ยง5.2.

Perhaps the SMB issue has the same root cause? Is there a way to see if the queue really isn't accepting jobs?
Comment 7 Dan Mossor [danofsatx] 2015-02-02 18:39:58 UTC 
I apologize for dropping the ball on this bug. I no longer have the hardware or software referenced herein, so I cannot provide the needed information. I am closing this bug for lack of required info.