direct IPP printing broken

[andyrtr]

I have a Samsung M2825DW IPP capable printer in my network connected with LAN cable. Running latest cups 2.3.0 and cups-filters 1.25.12 on a cups server and all clients I can print to a driverless queue @server from any client well. But printing from clients to the direct IPP queue created by cups-browsed fails with "HTTP_STATE_WAITING Closing for error 32 (Broken pipe)". cupsd.conf and cups-browsed.conf with default settings and no change with "CreateRemoteCUPSPrinterQueues No" and "CreateIPPPrinterQueues All". Any idea how to further track this down?

error_log.txt

[tillkamppeter]

Please edit /etc/cups/cups-browsed.conf on your client to have a line

DebugLogging file

in it and restart cups-browsed. On your server switch CUPS to debug logging:

cupsctl --debug-logging

On the client print a job to the cups-browsed-generated queue and attach the /var/log/cups/error_log of the server and the /var/log/cups/cups-browsed.log of the client to this issue. Note that you have to rename the files adding a .txt extension to make the attachments getting accepted by GitHub.

[andyrtr]

cups-browsed.txt
cups_error.txt

Print job starts at ~ 16/Nov/2019:14:19:31 +0100

[tillkamppeter]

Are you sure that your print job did not get printed? All lines in error_log which concern your print job (containing [Job 109]) make the impression that the job got correctly printed. No error in any of these lines, all filters exiting successfully, job getting completed and dequeued.
There is a line

D [16/Nov/2019:14:19:34 +0100] [Client 891] HTTP_STATE_WAITING Closing for error 32 (Broken pipe)

but it seems independent of the job.
The data is sent to the printer as 600-dpi Apple Raster. Did the printer actually print?
Could you run the command

ipptool -tv ipp://Samsung-Printer.local:631/ipp/print get-printer-attributes-2.0.test > attrs.txt

and if it does not work (or if attrs.txt is only a few lines long) run

ipptool -tv ipp://Samsung-Printer.local:631/ipp/print get-printer-attributes.test > attrs.txt

Please attach attrs.txt.

[andyrtr]

The printer doens't print out anything. 2nd ipptool command worked here. 1st didn't report anything back. Maybe I accidentally changed some option in the printers webinterface.

attrs.txt

[tillkamppeter]

Thank you, seems that the printer gets colored Apple Raster while it is a monochrome printer. "urf-supported" lists the variants of Apple Raster the printer understands and the only color space listed there is "W8", meaning "White, 8-bit".
@deepak0405, cups-browsed needs to tell more than only format and resolution to the implicitclass backend, color space/color depth is also needed, to be absolutely sure also paper size.

[tillkamppeter]

Could you also attach the PPD file of your print queue /etc/cups/ppd/Samsung_M2825DW_IPP.ppd? Please always add .txt to the file name before attaching.

[andyrtr]

Samsung_M2825DW_IPP.txt

[tillkamppeter]

I still do not have any clue why your print queue generated by cups-browsed produces data which the printer does not print, but the temporary queue of CUPS, with the same PPD file, produces output which gets printed.
So I need from you a CUPS error_log (in debug mode) which is from a job printed to the temporary CUPS queue (which the printer actually printed). Could you attach that?

[andyrtr]

This is the printjob using the fixed server queue. Log of the client and server.
client_error_log.txt
server_error_log.txt

Maybe I should also mention that when disabling/stopping cups-browsed on the client printing using cups own temporary self detected IPP queue also fails here.

[tillkamppeter]

"fixed server queue"? What did you actually fix on it?

[andyrtr]

Queue on the server: add new printer - choose IPP printer - check "shared" so it can be found from all clients "@server".

[tillkamppeter]

Thanks, found it out, too. So for you it printes when jobs go to the shared CUPS queue on the server, but directly printing to the printer from the clients, both with cups-browsed-generated queue or with temporary CUPS queue does not work.
I see the following difference now:
In the situation when printing worked (via CUPS server) the job got send with "InputSlot=Tray-1" This choice for an input tray does not exist ("Tray1" would be correct according to the PPD file you supplied earlier), so it is ignored and automatic tray selection used. This leads to the rastertopwg filter (generates Apple Raster) to use "MediaPosition = 0". This way you get a printout.
On direct printing from the client "InputSlot=Tray1" was sent and this exists in the PPD, gets selected and that sets "MediaPosition = 20" and this the printer does not print.
Eveb that in one case Poppler is used for the rasterization of the PDF and in the other Ghostscript, the page geometry, color mode, and color depth are the same, only the "MediaPosition" is different.
So try to print jobs in the case of direct printing from the client but supply "InputSlot=Auto". Does this print? Please also provide an error_log of that.

[tillkamppeter]

Could you also supply the file `/etc/cups/ppd/Samsung_IPP.ppd' from your server?

[andyrtr]

Samsung_IPP.ppd from server:
Samsung_IPP.txt

[andyrtr]

Tray set to "Auto" on the client:
server_error_log.txt

[tillkamppeter]

What is different is that the PPD file on your server got generated by cups-filters, due to the fact that you have set up the printer with a classic printer setup tool from good old driver times and I have created a legacy support feature (the driverless utility) in cups-filters which makes driverless printers appear in these tools.
When printing directly from the client, not using the server there are two cases: If cups-browsed is not running, CUPS creates a temporary print queue as soon as you try to print and this queue has a PPD generated by CUPS. If cups-browsed is running, cups-browsed first makes CUPS creating the temporary queue (by trying to retrieve the printer's options), downloads the PPD of the temporary queue (the one generated by CUPS) and replaces the temporary queue by a permanent one with this PPD.
The printer (printing from Tray 1 requested) prints with the PPD of cups-filters and not with the PPD of CUPS. The difference is most probably a coincidence, not a result of either me or Michael Sweet being more knowledgeable about doing it correctly. The PPD of CUPS sets "MediaPosition = 20" whereas the PPD of cups-filters does not do so. And the rastertopwg filter generating Apple Raster with "MediaPosition = 20" breaks your printing.
Best is you report a bug in CUPS ...

[tillkamppeter]

Firmware bug of the printer, according to the CUPS bug report. Closing.