Bug 781488

Summary: Printing fails to a Postscript printer using a PPD which worked in F14 and F15
Product: [Fedora] Fedora Reporter: Andrew Dingman <adingman>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: jpopelka, mathieu-acct, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-31 16:41:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
PPD for the Brother 9970CDW, as used on my working F15 box
none
output from the s-c-printer troubleshooting tool
none
network dump none

Description Andrew Dingman 2012-01-13 15:29:10 UTC
Created attachment 555088 [details]
PPD for the Brother 9970CDW, as used on my working F15 box

Description of problem:

Printing fails despite using a PPD which works perfectly on F14 and F15. If the printer is configured to auto-detect printer language, jobs appear as what looks to be hexadecimal garbage with line feeds but no carriage returns. If the printer is configured to expect PostScipt only, it prints a short error with a small ammount of hex garbage as the problematic "command" it received.


Version-Release number of selected component (if applicable): cups-1.5.0-22.fc16.x86_64


How reproducible:

Configure an IPP print queue for a Brother MFC-9970CDW. Provide the PPD, and use the attached PPD file


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Andrew Dingman 2012-01-13 15:33:45 UTC
Sorry, hit submit prematurely.

How reproducible: always

Steps to Reproduce:
1. Configure an IPP print queue for a Brother MFC-9970CDW.
2. Provide the PPD, and use the attached PPD file
3. Print a test page

Actual results:
Garbage, as described above.

Expected results:
Printer outputs a CUPS test page.


Additional info:
I still have a working F15 install on another machine in the same office, using the PPD above.

I have tried manually adding the PPD file to /usr/share/cups/ and picking it from the interface with no change in behavior. I have tried using the CUPS web interface instead of system-config-printer. I have tried shutting down CUPS and copying the printer description straight from the working F15 machine. None of these things change the observed behavior.

Comment 2 Andrew Dingman 2012-01-13 15:34:37 UTC
Created attachment 555090 [details]
output from the s-c-printer troubleshooting tool

Comment 3 Tim Waugh 2012-01-13 16:22:47 UTC
Please attach /etc/cups/ppd/homecolor.ppd.

I'd also like to see the output of this command:
  /usr/share/system-config-printer/check-device-ids.py homecolor

Comment 4 Jiri Popelka 2012-01-13 16:57:03 UTC
(In reply to comment #3)
> Please attach /etc/cups/ppd/homecolor.ppd.
I think that's the one attached in comment #0.


  'printer-state-reasons': [u'cups-ipp-conformance-failure-report',
                            u'cups-ipp-wrong-http-version'],
seems like some limitation of the printer's IPP implementation.
The ipptool from cups-ipptool package should be able to perform some tests to check this, but I haven't tried it yet.

Could try to use AppSocket protocol instead ?
See http://www.cups.org/documentation.php/network.html#PROTOCOLS

Comment 5 Andrew Dingman 2012-01-13 21:46:44 UTC
Jiri - I use IPP to print to this device from F15 sucessfully.

Tim:

adingman@sinope:~$ sudo /usr/share/system-config-printer/check-device-ids.py homecolor
URI for queue homecolor is ipp://brmfc.acdjdg.dingman.org/ipp
Sending SNMP request to brmfc.acdjdg.dingman.org/ipp for device-id
Skipping ipp://brmfc.acdjdg.dingman.org/ipp, insufficient data
No Device IDs available.
adingman@sinope:~$

Comment 6 Andrew Dingman 2012-01-13 21:50:18 UTC
However, I *do* get a perfectly nice print-out using app socket.

Comment 7 Tim Waugh 2012-01-16 13:23:45 UTC
Looks like a regression in the ipp backend between 1.4.8 and 1.5.0 then.

When using IPP, could you please capture the IPP traffic between the computer and the printer using e.g. wireshark or tcpdump?

e.g. tcpdump -U -s0 -w ipp.pcap port ipp

Then attach ipp.pcap here using the Add an attachment link above.

Comment 8 Matthias Kuhn 2012-07-07 09:26:47 UTC
Created attachment 596747 [details]
network dump

Comment 9 Matthias Kuhn 2012-07-07 09:39:10 UTC
Comment on attachment 596747 [details]
network dump

Request is HTTP/1.1
Response is HTTP/1.0

Is there a reason that cups is not able to fallback to HTTP/1.0?

As far as I can see, IPP requires HTTP/1.1 by definition, but it looks like not all the printer manufacturer are aware of that.

Comment 10 Tim Waugh 2012-10-31 16:41:24 UTC
CUPS is stricter about such requirements now for reasons of reliability.