[cups] LPD printer drops LPD chatting
Bryan Mason
bmason at redhat.com
Wed Nov 22 11:44:36 PST 2017
On Wed, 2017-11-22 at 20:08 +0100, Matthias Apitz wrote:
> Hello,
>
> I have a network printer which accepts jobs via LPD but drops the
> chatting during the initial commands:
...
> D [06/Nov/2017:13:04:07 +0100] [Job 191239] Sending command string
> (27 bytes)...
> D [06/Nov/2017:13:04:07 +0100] [Job 191239] Reading command status...
> D [06/Nov/2017:13:04:07 +0100] [Job 191239] Set job-printer-state-
> message to "Entfernter Host hat nicht mit dem Befehlstatusbyte
> geantwortet nach 300 Sekunden!", current level=WARN
> D [06/Nov/2017:13:04:07 +0100] [Job 191239] lpd_command returning 4
> D [06/Nov/2017:13:04:07 +0100] [Job 191239] Backend returned status 1
> (failed)
> What could be the reason for not answering the control commands?
I think that's something that you'd need to ask the printer
manufacturer. There's no way to tell from this data.
In general, I recommend using a protocol other than LPD (like
"socket://") if the printer supports it. My experience is that LPD has
all sorts of interesting problems whereas Socket is pretty robust
(probably due to its simplicity).
> Btw: Why the backend lpd is using a local port below 1024?
RFC 1179 actually specifies that the local port should be in the range
from 721-731. The CUPS lpd backend relaxes this a little and just uses
a privileged port (below 1024). You can change this behavior by adding
"?reserve=none" to the end of the Device URI (https://www.cups.org/doc/
network.html#LPD), although it's possible that the printer won't accept
a connection from a non-privileged port.
~ Bryan
More information about the cups
mailing list