[cups-devel] When accessing HP DeskJet Ink Advantage 254x IPP-over-USB does everything but printing

Michael Sweet msweet at apple.com
Mon Jul 13 10:43:41 PDT 2015


Till,

This looks like an ippusbxd bug - it isn't handling the chunked transfer encoding for requests properly, leading to lockups like you are seeing.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

> On Jul 8, 2015, at 6:59 PM, Till Kamppeter <till.kamppeter at gmail.com> wrote:
> 
> Hi,
> 
> I have the HP DeskJet Ink Advantage 2546 multi-function printer with USB and WiFi connections for testing IPP-over-USB integration in Ubuntu.
> 
> What works perfectly is accessing it via conventional USB ("hp" backend of HPLIP or "usb" backend of CUPS) or via WiFi (Configure WiFi via hp-wificonfig of HPLIP or via the web interface after setting up IPP-over-USB, then access as to a network printer, via the "ipp" backend of CUPS or the "hp" backend of HPLIP). Scanning via HPLIP and SANE also works.
> 
> For IPP-over-USB I run the ippusbxd daemon from Daniel Dressler which is available here:
> 
> https://github.com/tillkamppeter/ippusbxd
> 
> I use the following command line:
> 
> ippusbxd -l -v 03f0 -m c211 -s BR54BFB02C05XK -P 60000
> 
> which makes the printer's IPP interface available under the device URI
> 
> ipp://localhost:60000/ipp/print
> 
> and the printer's web interface under
> 
> http://localhost:60000/
> 
> I can navigate through the web interface, configure the printer and scan via the web interface.
> 
> I can also do IPP queries using ipptool, but I cannot print straight away.
> 
> First I tried to print with CUPS creating a queue with the PPD file from HPLIP and the device URI ipp://localhost:60000/ipp/print, also adding "?version=XXX" with 1.0, 1.1, 2.0 does not work. The job goes through the filters but dows not go off to the printer. It simply hangs.
> 
> If I use the old "ipp" backend of CUPS 1.4.x (I include it in Ubuntu with the name "ipp14", to support printers with buggy IPP implementations) it prints once but after that the printer is in "Print file was not accepted (Success)!" state and the job not taken out of the queue.
> 
> Now I tested also printing without CUPS but with ipptool. For that I use a JPG file (can be any image from the web or from a digital camera) and the /usr/share/cups/ipptool/print-job.test test instruction file.
> 
> The straight command line
> 
> ipptool -t -d filetype=image/jpeg -d filename=/home/till/Pictures/paris.jpg ipp://localhost:60000/ipp/print /usr/share/cups/ipptool/print-job.test > log
> 
> takes some time and gives "(null)" on STDERR and "log" contains:
> 
> "/usr/share/cups/ipptool/print-job.test":
>    Print file using Print-Job                             [FAIL]
>        RECEIVED: 0 bytes in response
>        status-code = successful-ok ((null))
>        IPP request failed with status successful-ok ((null))
> 
> Same if I specify an IPP version with the -V option. I tried all available versions.
> 
> If I use the device URI for acessing the printer via WiFi (ipp://<IP address>:631/ipp/print) the printer prints correctly.
> 
> Also specifying the "-C" option (HTTP/1.1, "Transfer-Encoding: chunked") leads to the same behavior.
> 
> I CAN print arbitrarily many jobs via IPP-over-USB only by specifying the "-L" option (HTTP/1.0, "Content-Length:") to ipptool:
> 
> ipptool -t -L -d filetype=image/jpeg -d filename=/home/till/Pictures/paris.jpg ipp://localhost:60000/ipp/print /usr/share/cups/ipptool/print-job.test > log
> 
> making ipptool close quickly without any output on STDERR and the following in "log":
> 
> "/usr/share/cups/ipptool/print-job.test":
>    Print file using Print-Job                            [PASS]
> 
> The job gets immediately printed after ipptool exiting. If I send another job with the same command line while it is still printing I get a "server-error-busy", meaning that most probably there is no print queue managed in the printer. After the printout being finished I can send another job and this way print arbitrarily many print jobs with this ipptool command line.
> 
> So this means that IPP printing on this printer via IPP-over-USB is only possible with ipptool forcing HTTP/1.0, "Content-Length:" and not with the regular CUPS "ipp" backend. The old CUPS-1.4.x backend has probably some HTTP/1.0 fallback but I did not investigate this.
> 
> What does this mean? Does the printer have a bug in its IPP implementation? Does the CUPS "ipp" backend have a bug (need to report this as CUPS STR), or does ippusbxd have a bug (less probable as web interface and non-printing IPP requests work).
> 
>   Till
> _______________________________________________
> cups-devel mailing list
> cups-devel at cups.org
> https://www.cups.org/mailman/listinfo/cups-devel




More information about the cups mailing list