Home / server / Questions / 578246
In Process
Wayne Conrad
Asked: 2014-02-26 11:56:11 +0800 CST

Printer lpd daemon refuses print job if a command's new-line sent separately -- bug?

  • 772

I'm encountering some printer LPD daemons which work fine if the new-line is sent in the same packet as the command, but break if the new-line is sent in a separate packet. Is that a bug in these particular daemons?

The LPD protocol is driven by one-line commands terminated with new-line. From RFC 1179:

A line printer daemon responds to commands send to its port. All commands begin with a single octet code, which is a binary number which represents the requested function. The code is immediately followed by the ASCII name of the printer queue name on which the function is to be performed. If there are other operands to the command, they are separated from the printer queue name with white space (ASCII space, horizontal tab, vertical tab, and form feed). The end of the command is indicated with an ASCII line feed character.

This Ruby code was being used to send such a command:

socket.puts command

Internally, Ruby treats this as two separate socket writes

socket.print command
socket.print "\n"

Which can occasionally cause two packets to be sent, one of the command, and one for the new-line. That doesn't seem consistent with Nagle's Algorithm, as I understand it, but I've verified with tcpdump that it is indeed happening. When the command and new-line get sent separately, some LPD daemons do not accept the print job, but instead either disconnect, or respond to the command with something other than a \0 (an ACK, per the RFC).

If I change this code to:

socket.print command + "\n"

so that the command and its new-line are always sent together, these daemons work fine.

The LPD daemons with this behavior are in printers, with sizes ranging from desktop to factory-floor. I either don't have access to their LPD daemon logs, or the logs reveal nothing. The printers are mostly opaque to me; I have either limited or no access to the LPD on the printer (I don't even know what LPD daemon is running on each printer).

Not all LPD daemons are affected by this behavior. For example, printing to LPRNG's daemon, or CUPs, works fine even when new-lines are sent in a separate packet.

It this a bug, or is there something about TCP/IP or the LPD protocol that I'm missing?

tcpip

0 Answers