This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 518065 - IPP-Get-Printer-Attributes request never finishes
IPP-Get-Printer-Attributes request never finishes
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
:
Depends On:
Blocks: fitandfinish
  Show dependency treegraph
 
Reported: 2009-08-18 12:39 EDT by Yulia Kopkova
Modified: 2009-10-13 22:01 EDT (History)
3 users (show)

See Also:
Fixed In Version: 1.4.1-4.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-13 22:01:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
tcpdump -s0 -U -w ipp.tcp tcp port ipp (955.65 KB, application/octet-stream)
2009-08-18 13:59 EDT, Jiri Popelka
no flags Details
tcpdump -s0 -U -w ipp.tcp tcp port ipp (213.79 KB, application/octet-stream)
2009-08-19 04:27 EDT, Yulia Kopkova
no flags Details
Warning that print share is not accessible (37.96 KB, image/png)
2009-08-19 06:42 EDT, Jiri Popelka
no flags Details
Printing to ipp://canon-address/ipp (58.09 KB, image/png)
2009-08-19 06:47 EDT, Jiri Popelka
no flags Details
Troubleshoot report (26.15 KB, text/plain)
2009-08-19 06:48 EDT, Jiri Popelka
no flags Details
tcpdump from F10 (1.62 KB, application/octet-stream)
2009-08-20 05:56 EDT, Jiri Popelka
no flags Details
tcpdump after we've given up verifying the queue (162.46 KB, application/octet-stream)
2009-08-21 05:40 EDT, Jiri Popelka
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 3311 None None None Never

  None (edit)
Description Yulia Kopkova 2009-08-18 12:39:06 EDT
Description of problem:
S-c-p hangs when press "Verify" button for IPP printer Canon iR 3170C EUR. 

Version-Release number of selected component (if applicable):
system-config-printer-1.1.10-8.fc12.i686

How reproducible:
Always

Steps to Reproduce:
1. Add new network IPP printer. Host: "my.printer.com", Queue: "/ipp"
2. URI ipp://my.printer.com/ipp
3. Press "Verify" button
  
Actual results:
S-c-p hangs

Expected results:
S-c-p verify printer

Additional info:
Tested on 2 printers of this model.
Comment 1 Tim Waugh 2009-08-18 13:03:58 EDT
That's strange.  What IPP traffic is there?

tcpdump -s0 -U -w ipp.tcp tcp port ipp
Comment 2 Jiri Popelka 2009-08-18 13:59:28 EDT
Created attachment 357835 [details]
tcpdump -s0 -U -w ipp.tcp tcp port ipp

I experienced the same behavior on the same printer (I'm with Yulia in the same office) on F-11 and F-12.
Comment 3 Yulia Kopkova 2009-08-19 04:27:34 EDT
Created attachment 357901 [details]
tcpdump -s0 -U -w ipp.tcp tcp port ipp

IPP traffic from another one Canon iR 3170C EUR
Comment 4 Jiri Popelka 2009-08-19 06:42:47 EDT
Created attachment 357915 [details]
Warning that print share is not accessible

In F-10 (1.0.x) there's warning that the print share is not accessible after pressing the "Verify..." button.
(And the same for 1.1.x after Tim yesterday added (to GIT) using of separate thread for verifying IPP queue.)
Comment 5 Jiri Popelka 2009-08-19 06:47:08 EDT
Created attachment 357916 [details]
Printing to ipp://canon-address/ipp

Maybe this can be somehow related to problem I once discussed with Tim.

On 06/26/2009 05:35 PM, Jiri Popelka wrote:
> Hi Tim,
>
> We have cups server running on file.brq.redhat.com here in Brno office.
> One of available printers is Canon iR 3170C.
> cupstree.py says:
> * Name:    canon-printer-2nd-entrance[@localhost]
> URI:    ipp://file.brq.redhat.com:631/printers/canon-printer-2nd-entrance
> Info:    Canon, 2nd floor, entrance area
>  * Name:    canon-printer-2nd-entrance[@file.brq.redhat.com]
>  URI:    http://canon-printer-2nd-entrance.brq.redhat.com/ipp
>  Info:    Canon, 2nd floor, entrance area
>
> Printing on this printer using file.brq.redhat.com is all right.
>
> Canon iR 3170C supports IPP natively, so what if I want to print directly (no file.brq.redhat.com) using IPP ?
> If I use cups web interface (localhost:631) to add this printer using Internet Printing Protocol (http or ipp),
> everything (even printing test page) looks good.
>
> But if I try to print on this printer using system-config-printer or other program (I tried Evince, gedit and lp),
> the system-config-printer-applet claims there's some printer error - but the page is printed perfectly.
>
> If I try to add (using ipp) this printer in system-config-printer and try the "Verify..." button I get "This print share is not accessible".
>
> I tried to add port-number like:
> http://canon-printer-2nd-entrance.brq.redhat.com:80/ipp
> or
> http://canon-printer-2nd-entrance.brq.redhat.com:631/ipp
> but that's the same.
>
> I add troubleshoot.txt (I don't see anything stuffy there).

On 06/26/2009 06:35 PM, Tim Waugh wrote:
>
> Unfortunately there's not a lot that can be done.  The printer is
> telling us 'other-warning', and since it is not 'other-report' (which
> would be just informational) we aren't supposed to ignore it
>
> This seems to be an instance where the IPP support in the printer is not
> particularly good. :-(
>
> Tim.
> */
Comment 6 Jiri Popelka 2009-08-19 06:48:40 EDT
Created attachment 357917 [details]
Troubleshoot report
Comment 7 Tim Waugh 2009-08-19 07:06:42 EDT
(In reply to comment #4)
> (And the same for 1.1.x after Tim yesterday added (to GIT) using of separate
> thread for verifying IPP queue.)  

It seems as though the getPrinterAttributes() call is trying over and over again, while the printer is giving HTTP 404 errors each time.

I don't think the thread stuff I added in 1.1.x really helps with that, just lets the UI continue while that's happening.

Can you see if that's the case, i.e. whether we're still trying to fetch attributes over and over again even after the 'not accessible' dialog is displayed?
Comment 8 Jiri Popelka 2009-08-19 07:55:58 EDT
As I understand it the getPrinterAttributes() is called only once.

Calling <function get_attributes at 0x7ffcc0a35140>
-> Connection_init(host=10.34.255.21)
begin allow threads
httpConnectEncrypt(...)
end allow threads
<- Connection_init() = 0
-> Connection_getPrinterAttributes(ipp://10.34.255.21/ipp)
trying request with uri ipp://10.34.255.21/ipp
begin allow threads
Command canceled
get_notifications
-> Connection_init(host=/var/run/cups/cups.sock)
begin allow threads
httpConnectEncrypt(...)
end allow threads
<- Connection_init() = 0
-> Connection_getNotifications()
begin allow threads
end allow threads
<- Connection_getNotifications()
update_jobs
httpClose()
Comment 9 Tim Waugh 2009-08-19 08:04:46 EDT
It's only called once, but notice there is no return from that function reported.  I think we still have a thread running in libcups, repeatedly sending IPP-Get-Printer-Attributes requests to the printer.  Take a look with tcpdump.
Comment 10 Jiri Popelka 2009-08-20 05:56:07 EDT
Created attachment 358059 [details]
tcpdump from F10

The same in Fedora 10 (for comparison).

-> Connection_init(host=10.34.255.21)
begin allow threads
httpConnectEncrypt(...)
end allow threads
<- Connection_init() = 0
getAttributes
uri:  ipp://10.34.255.21/ipp
-> Connection_getPrinterAttributes(ipp://10.34.255.21/ipp)
trying request with uri ipp://10.34.255.21/ipp
begin allow threads
end allow threads
set_ipp_error: 1030, client-error-not-found
<- Connection_getPrinterAttributes() (error)
Failed to get attributes: client-error-not-found (1030)
httpClose()
Comment 11 Jiri Popelka 2009-08-20 06:16:57 EDT
I see the same with CUPS-Get-Printers operation.
I have queue with uri ipp://10.34.255.21/ipp added
and try to run pycups/examples/cupstree.py

In F10 Connection_getPrinters() raises cups.IPPError (because 10.34.255.21 is not a CUPS server but network printer)
but in F11 the Connection_getPrinters() never returns.
Comment 12 Tim Waugh 2009-08-21 04:47:57 EDT
Seems like a libcups problem.

Can you confirm that there is TCP traffic as in comment #2 after we've supposedly given up verifying the queue?

Can you try 1.0.x but with the same cups (run it from the git repo with 'make run') to see if that behaves as it did in Fedora 10 (bet it won't)?
Comment 13 Jiri Popelka 2009-08-21 05:40:24 EDT
Created attachment 358212 [details]
tcpdump after we've given up verifying the queue

(In reply to comment #12)
> Seems like a libcups problem.
> 
> Can you confirm that there is TCP traffic as in comment #2 after we've
> supposedly given up verifying the queue?
cups-1.4-0.rc1.15.fc11.x86_64
cups-libs-1.4-0.rc1.15.fc11.x86_64
s-c-printer 1.1.11 (git)
Yes, there is (see attachment) still TCP traffic after we've given up verifying the queue.
It stops after I've closed s-c-p.

> 
> Can you try 1.0.x but with the same cups (run it from the git repo with 'make
> run') to see if that behaves as it did in Fedora 10 (bet it won't)?  

cups-1.4-0.rc1.15.fc11.x86_64
cups-libs-1.4-0.rc1.15.fc11.x86_64
s-c-printer  1.0.16  (git)

<- Connection_init() = 0
-> Connection_getPrinterAttributes(ipp://10.34.255.21/ipp)
trying request with uri ipp://10.34.255.21/ipp
begin allow threads

s-c-printer hangs and the tcp traffic runs forever
Comment 14 Jiri Popelka 2009-08-27 09:00:32 EDT
Patch
http://cups.org/strfiles/3311/0001-Prevent-infinite-loop-in-cupsDoIORequest.patch
fixes this issue.

Calling <function get_attributes at 0x22e96e0>
-> Connection_init(host=10.34.255.21)
begin allow threads
httpConnectEncrypt(...)
end allow threads
<- Connection_init() = 0
-> Connection_getPrinterAttributes(ipp://10.34.255.21/ipp)
trying request with uri ipp://10.34.255.21/ipp
begin allow threads
end allow threads
set_ipp_error: 1030, client-error-not-found
<- Connection_getPrinterAttributes() (error)
Caught exception (1030, 'client-error-not-found')
httpClose()
Failed to get attributes: client-error-not-found (1030)
Comment 15 Tim Waugh 2009-08-27 09:15:46 EDT
Great, thanks for confirming.
Comment 16 Jiri Popelka 2009-09-01 12:03:28 EDT
(In reply to comment #5)
BTW
The problem described in comment #5 (the system-config-printer-applet claims there's some printer error - but the page is printed perfectly.) disappeared after I added /?waitjob=false to device URI. So the whole device URI looks like ipp://10.34.255.21/ipp/?waitjob=false

I found it on http://www.linuxfoundation.org/en/OpenPrinting/Database/CanonFAQ#Canon_ImageRunner_iR
Comment 17 Tim Waugh 2009-09-02 04:07:33 EDT
Hmm, I wonder if we should have a check-box in system-config-printer for that.  (Anyway, that's a separate bug.)
Comment 18 Fedora Update System 2009-09-30 10:20:04 EDT
cups-1.4.1-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/cups-1.4.1-1.fc11
Comment 19 Fedora Update System 2009-09-30 20:06:25 EDT
cups-1.4.1-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cups'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10152
Comment 20 Fedora Update System 2009-10-03 14:59:48 EDT
cups-1.4.1-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cups'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10152
Comment 21 Fedora Update System 2009-10-08 23:36:53 EDT
cups-1.4.1-4.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cups'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10152
Comment 22 Fedora Update System 2009-10-13 22:00:15 EDT
cups-1.4.1-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

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