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.
That's strange. What IPP traffic is there? tcpdump -s0 -U -w ipp.tcp tcp port ipp
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.
Created attachment 357901 [details] tcpdump -s0 -U -w ipp.tcp tcp port ipp IPP traffic from another one Canon iR 3170C EUR
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.)
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. > */
Created attachment 357917 [details] Troubleshoot report
(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?
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()
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.
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()
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.
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)?
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
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)
Great, thanks for confirming.
(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
Hmm, I wonder if we should have a check-box in system-config-printer for that. (Anyway, that's a separate bug.)
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
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
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
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
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.
Thank you and thank you again, I really need this software because the printer spooler and sometime driver problem are very annoying, I hope this program will help me a lot, for more visit http://printertechsupportnumbers.com/blog/fix-epson-wf-3620-error-code-0x97/