lprint icon indicating copy to clipboard operation
lprint copied to clipboard

Lprint is sensitive to both system hostname and server name

Open mairas opened this issue 9 months ago • 3 comments

Here's something very, very weird that I've been struggling with for the past 10 hours or so. lprint seems to be very finicky about the system hostname settings.

Here's what I have:

My home office network uses both mDNS (*.local) and and actual DNS server (with the domain *.hal, dynamically populated by the router from the DHCP data) to resolve host addresses.

I have an existing print server, let's call it print.local, that is a proxmox container running Debian bookworm (amd64) with a self-built lprint server (I had trouble getting snap to work inside the container).

I have two USB label printers connected to print.local:

  • Munbyn ITPP941, a generic 203dpi TSPL printer
  • Vevor Y428BT, a generic 300dpi TSPL printer.

Both have been working without any issues: I've been printing to both on Mac command line and GUI apps.

Next, I got a Raspberry Pi CM4 device called pi.hal (arm64, running Raspeberry Pi OS Bookworm) and installed lprint on it using snap. Fairly straightforward. I can print a .png file to both printers using lprint on the command line.

Then, the troubles start. On pi.hal command line, lp -d VevorPi debug_output_ADDRESSLABEL_20240506173419.pdf results in no output. Debug logging gives the following:

Validate-Job request:   print-quality enum 0
...
Validate-Job response: IPP/2.0 request-id=2, status-code=client-error-attributes-or-values-not-supported
...
Validate-Job response:   status-message textWithoutLanguage Unsupported print-quality enum value.

Same happens with the Munbyn printer.

Mac behavior is even stranger. I could see and install the printers on the system print dialog but printing a PDF label using the preview app is first stuck in "Processing page: 1" and then after a longish time, in Print Center, the print job appears and the printer goes offline. As soon as I pause the job, the printer immediately comes back online.

This all worked on print.local. I went through the lprint.state files on both machines and couldn't find any differences, and also the server command line arguments were identical. I tried also a self-built lprint on pi.hal, but that didn't make a difference.

Changing the server-name option on pi.hal to either pi.hal or pi.local seemed to cause some change in the Mac behavior, and then I noticed the other server /etc/hostname was print.local, so I tried changing the Pi /etc/hostname to pi.local. After that, printing to either printer worked, both locally, from a remote Linux host, and from the Mac laptop.

I also tried setting /etc/hostname to a "bare" hostname: pi. This resulted in printing from the Mac laptop still working, but when printing from another Linux with lp, I got the same "print-quality enum 0" thing as above.

As said, I spent quite a few hours debugging this issue. There was really no hint that any of the errors would be related to the hostname. At some point I got errors in the debug level log about bad hostname or something similar - I wonder is lprint too restrictive in its hostname matching? I think none of this would've happened if only the bare hostname was matched to the request.

mairas avatar May 07 '24 18:05 mairas

The blabbering above was of course coincidental. Now I am getting that error regardless of the hostname:

May 13 14:09:22 shopship.local lprint.lprint-server[694]: I [2024-05-13T11:09:22.916Z] [Client 12] Validate-Job client-error-attributes-or-values-not-supported (Unsupported print-quality enum value.)

I will continue investigating and will report when I find anything.

mairas avatar May 13 '24 11:05 mairas

Printing succeeds if I set -o cupsPrintQuality=Normal:

lp -d VevorPi -o media=101x220mm -o cupsPrintQuality=Normal -o print-scaling=none debug_output_shipping_label_20240513105329.pdf```

Setting the same option as default does not help:

sudo lpadmin -d VevorPi -o cupsPrintQuality-default=Normal

mairas avatar May 13 '24 11:05 mairas

OK, so you are having a bunch of problems, and not all of them related I think.

The CUPS "lp" and "lpadmin" command issues are specific to CUPS and not LPrint. The "print-quality" option is what IPP calls an enum value - 3 is draft, 4 is normal, and 5 is high or best quality. The strings are only supported for the "cupsPrintQuality" option which is part of the PPD options. The default PPD option name is "DefaultcupsPrintQuality", not "cupsPrintQuality-default"...

michaelrsweet avatar May 14 '24 18:05 michaelrsweet