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

[Till Kamppeter]

Hi,

I have found a fix now. Chunked transfers were not done completely, see

https://github.com/tillkamppeter/ippusbxd/commit/3facde24a3b74168047dcd564bf609fd9911edcb

Thank you all for any hints you have given.

    Till

On 07/08/2015 07:59 PM, Till Kamppeter 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