ipp-usb: cannot print on HP m28a on ArchLinux

[rilian-la-te]

from /var/log/ipp-usb/device.log

10-07-2022 21:04:57:   USB[0]: connection allocated, 1 in use: a-- --- ---
10-07-2022 21:04:57:   HTTP[074]: connection 0 allocated
10-07-2022 21:04:57: > USB[0]: write: wanted 976 sent 976 total 976
10-07-2022 21:04:57: < USB[0]: read: wanted 4096 got 0 total 0
10-07-2022 21:04:57: ! USB[0]: zero-size read
10-07-2022 21:04:57: < USB[0]: read: wanted 4096 got 1024 total 1024
10-07-2022 21:04:57: < HTTP[074]: POST http://localhost:60000/ipp/print - 200 OK
10-07-2022 21:04:57: < HTTP[074]: HTTP response header:
10-07-2022 21:04:57: <   HTTP/1.1 200 OK
10-07-2022 21:04:57: <   Content-Length: 981
10-07-2022 21:04:57: <   Content-Type: application/ipp
10-07-2022 21:04:57: <
10-07-2022 21:04:57: < USB[0]: read: wanted 4096 got 0 total 1024
10-07-2022 21:04:57: ! USB[0]: zero-size read
10-07-2022 21:04:57: < USB[0]: read: wanted 4096 got 0 total 1024
10-07-2022 21:04:57: ! USB[0]: zero-size read
10-07-2022 21:04:57: < USB[0]: read: wanted 4096 got 0 total 1024
10-07-2022 21:04:57: ! USB[0]: zero-size read
10-07-2022 21:04:57: < USB[0]: read: wanted 4096 got 28 total 1052
10-07-2022 21:04:57: < HTTP[074]: response body: got 981 bytes; EOF
10-07-2022 21:04:57:   USB[0]: connection released, 0 in use: --- --- ---

keep-alive quirk is set for M28a.

[alexpevzner]

Hi,

the log fragment that you've published doesn't contain any problem by itself. zero-size reads are not problem, but sometimes correlate with real problems, though there are a lot of devices that have zero-size reads but work absolutely reliable.

First thing to do, is to isolate the problem to the particular component (it may be on CUPS side, for example).

If your device has a scanner, I suggest to try to scan with sane-airscan. Also, you printer may expose its web console via IPP-USB, I suggest you to try it with web browser (http://localhost:60000 in most cases)

[alexpevzner]

Btw, I see you are from Moscow, like me. Where are you located here?

[rilian-la-te]

@alexpevzner in Butovo xD

Scanning works. Web-browser page too. But printing is not - KDE reports than "job is cancelled by printer" for any page, even test one. HPLIP works.

[alexpevzner]

@alexpevzner in Butovo

Very near to me. I'm in Yasenevo.

Scanning works. Web-browser page too. But printing is not - KDE reports than "job is cancelled by printer" for any page, even test one. HPLIP works.

ipp-usb is only a transport. Job can be cancelled due to many reasons. If after failed printing job all IPP-USB interfaces are idle:

10-07-2022 21:04:57:   USB[0]: connection released, 0 in use: --- --- ---

this is very unlikely that the problem is in the ipp-usb.

My Kyocera also doesn't work out of box with the open source stack. For me, it helps to extract the .PPD file from the proprietary driver bundle and to manually install it on CUPS.

@tillkamppeter, can you help us, please? How to solve problems like these?

[tillkamppeter]

@rilian-la-te here we would need some more information:

• If there is a way to connect the printer by Ethernet or Wi-Fi instead of USB, it should also do driverless printing and scanning. Is it working completely and correctly this way or do you get the same printing problem?
• To investigate the printing problem itself you should put CUPS into debug logging mode (cupsctl --debug-logging) and print another (failing) job. After that get the /var/log/cups/error_log file and attach it here. Note that GitHub only accepts it if you rename it to have the extension .txt.
• Also attach the PPD file of your CUPS queue (in /etc/cups/ppd/, also rename it to have a .txt extension for attaching it).
• Get further info from your printer with the command ipptool -tv ipp://localhost:60000/ipp/print get-printer-attributes.txt > attrs.txt Attach the file attrs.txt to this bug report.

Please attach the files one by one, do not compress them and do not package them together. Thanks.

[rilian-la-te]

@tillkamppeter will do.

Printer do not support ethernet.

I will do attaching PPD and other files.

[rilian-la-te]

@tillkamppeter

Logs:
error_log.txt
attrs.txt
printer.ppd.txt

[debiantriage]

@tillkamppeter

The error_log has

[Job 33] PID 2492 (/usr/lib/cups/backend/ipp) stopped with status 5.
[Job 33] Job canceled at printer.

Earlier in the log:

[Job 33] 5 filters for job:
[Job 33] bannertopdf (application/vnd.cups-pdf-banner to application/pdf, cost 32)
[Job 33] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
[Job 33] gstoraster (application/vnd.cups-pdf to image/pwg-raster, cost 99)
[Job 33] - (image/pwg-raster to printer/hp-home/image/pwg-raster, cost 10)
[Job 33] - (printer/hp-home/image/pwg-raster to printer/hp-home, cost 0)
[Job 33] envp[27]="FINAL_CONTENT_TYPE=image/pwg-raster"

Why produce PWG raster when the cost factor for Apple raster in the PPD is 0?

*cupsFilter2: "image/urf image/urf 0 -"
*cupsFilter2: "image/pwg-raster image/pwg-raster 10 -"

@rilian-la-te

You could try printing with the everywhere mode:

• Obtain a URI with driverles.
• Execute lpadmin -p testq "URI" -E -m everywhere, substituting for URI, of couse.
• Print with lp -d testq /etc/nsswitch.conf.

[tillkamppeter]

@rilian-la-te please also do the following:

sudo systemctl stop cups

Then edit the PPD file of your printer in /etc/cups/ppd/. It has the name of your print queue. Remove the line
*cupsFilter2: "image/pwg-raster image/pwg-raster 10 -". Save the file.
The start CUPS again:

sudo systemctl start cups

Try to print again. Does this work now?

[rilian-la-te]

@tillkamppeter nope, same symptoms. Removing cups-filter is not working.

[rilian-la-te]

@debiantriage everywhere mode is also does not work.

[rilian-la-te]

New log:
error_log.txt

[debiantriage]

Jobs 34 and 37 are printer on hp-home. Both use the expected six filters successfully and an Apple raster file reaches the printer . (It takes a few attempts in Job 34 to resolve the device URI). Having reached the printer we then see

D [21/Jul/2022:22:33:50 +0300] [Job 34] (monitor) job-state = aborted
D [21/Jul/2022:22:33:50 +0300] [Job 34] (monitor) job_canceled = -1
D [21/Jul/2022:22:33:50 +0300] [Job 34] JOBSTATE: document-format-error
I [21/Jul/2022:22:33:52 +0300] [Job 34] Job canceled at printer.

I would question whether this is an ipp-usb issue.

[debiantriage]

Jobs 35, 36 and 38 are printed on testq. For nsswitch.conf we see

I [21/Jul/2022:22:38:22 +0300] [Job 35] File of type text/plain queued by "rilian".
D [21/Jul/2022:22:38:22 +0300] [Job 35] Sending job to queue tagged as raw...

Sending as raw should not happen with a correctly set up everywhere queue. No filtering takes place; nsswitch.conf is sent without any filtering and the M28a cannot possibly print it.

@rilian-la-te

Thanks for the input but, unfortunately, it does not seem to provide any definite useful information about the operation of ipp-usb. The lpadmin command should produce a PPD in /etv/cups/ppd after querying the printer. Does it?

[rilian-la-te]

@debiantriage

testq.ppd.txt

With second attempt, nsswitch.conf is printed using Everywhere generator. Other jobs are still canceled