- Pharos Uniprint v8.3 and newer (these versions use Pharos Secure Release Service)
- Pharos Blueprint (all versions)
- Pharos MobilePrint
LPR/LPD is a TCP/IP application that transmits a print job from a client to a print device. LPR means "Line Printer Request" and is the client-side component of the transmission, and LPD, or "Line Printer Daemon" is the server-side (in this case, printer-side) component. By default, this communication occurs over TCP port 515. Microsoft has supported LPR/LPD beginning with Windows NT 3.51, is native to all Unix/Linux systems, and is supported by CUPS in MacOS X and Linux variants. Since the inception of Pharos Blueprint's Secure Release Here(tm), and beginning with Pharos Uniprint 8.3, print job delivery after release from a Pharos terminal occurs via an LPR event from the Pharos product server to the physical print device. This drags a lot of sites kicking and (sometimes) fussing into new technologies and possibly workflows.
Printers must support/provide LPD in order to support Secure Release Here from the above-mentioned Pharos software solutions (1). There is a Pharos Knowledge Base article found at http://pharos.custhelp.com/app/answers/detail/a_id/1872 that discusses how to work around the scenario where the device can't support LPD, or does a poor job of it. How this is configured varies by printer make/model, so consult your device's documentation in order to configure your printer(s) appropriately. There is nothing that needs to be done on the Pharos server, as our software has the LPR function built into the Pharos Systems Secure Release Service.
When a job is released from a terminal and does not print, one of the places to look is in the LPR/LPD path. Pharos logs (Uniprint: Print Service log; Blueprint: TaskMaster, Secure Release, and Job Service logs) will indicate where the release problem occurs. For example, you may see an "The LPR command did not receive an acknowledgement from the LPD server 'Printer Name or IP Address'" message. How do you know where to start?
It is first important to understand that LPR/LPD is a very simple application; there aren't a lot of moving parts, but since it is a TCP-based protocol, the client (LPR) and server (LPD) must have a consistent connection during the process, or the transmission will fail. Here's a simplistic overview of the exchange:
- LPR: "LPD, are you listening on TCP port 515 from this IP address?"
- LPD: "I'm listening."
- LPR: "OK, I'm going to send a print job."
- LPD: "I'm good with that."
- LPR: "Good. Here's the control file."
- LPD: "Got it."
- LPR: "Here's the data file."
- LPD: "Got it."
At any point that LPR seeks confirmation, it can be refused by LPD. The document that describes LPR/LPD (RFC 1179 for those in the mood for some riveting reading) lists the various return codes. Similarly, when either the control or data file are being transmitted, LPD can also send return codes. When sent by LPD, our LPR implementation adds all error return codes to the appropriate Pharos log file.
Step 1. Device Support of LPD.
This is the crucial first step. The device's documentation should be able to tell you if the printer supports LPD, and how to configure it.
Step 2. Check if you can reach the device.
PING and TRACERT are less useful here, but they do tell you if the device is there and the hops to get to it.
Two command line tools that can be used to learn more are:
TELNET is a utility that allows you to make a connection to a remote host using a specific port number. TELNET was once installed automatically with Windows Server and Windows XP, but you must install after-the-fact in Windows Vista - 8, and with Windows Server 2008 and higher as TELNET Client. In a command prompt, you simply type:
telnet <ipaddress> 515
and see if the connection is made. If you get a positive response, the command prompt windows will go black, as the LPD server is awaiting a command. Press the ENTER key and you'll get an "illegal service command" message while getting kicked out. If not successful, you'll receive a "Could not open connection to the host..." message. As an aside, TELNET is useful in checking for any communication port where the port that you are checking may change based on what service you are testing. One caveat to TELNET: it simply makes a connection to the specified TCP port, it is not validating that the process listening on the other side is functioning correctly. In the case of LPD and TCP 515, there have been many cases where the device is listening (TELNET to 515 is successful), but the LPD service itself is not operational. If this is the case, the best "next step" is to reload firmware on the printer or network card...potentially with an updated version.
The LPQ utility is only available if Print Services for Unix (Windows 2000, Server 2003, XP) or LPR (Windows Vista - 8, Server 2008 and higher) is installed. LPQ is the "Line Printer Query" utility. It has this syntax:
LPQ -S <ipaddress> -P <queue_name>
which requires that you know the queue name used by the print device. Again, your device's documentation will prove helpful here, but there are some standards:
Canon imageRUNNERs: lp or SPOOL
EFI Fiery front-ends: print or hold
Hewlett-Packard LaserJet printers: raw or raw1
Tektronix Phaser (includes Xerox Phaser): PS, PCL, or AUTO
Xerox WorkCentre: lp
A fairly comprehensive list can be found at http://www-912.ibm.com/s_dir/SLKBase.nsf/0/b49aa3cf3ce97d0d862565c2007d4393?OpenDocument for reference.
When successful, you may get a message that says "No entries" and you may get additional information about IDLE status, online/offline, etc.
If either LPQ or TELNET fail, and Step 1 passed successfully, then TCP 515 is blocked by either a firewall or router rule.
Step 3. Use Wireshark or Microsoft Network Monitor
If both steps 1 and 2 succeed, but the job is still failing to print, the next step is to use a packet capture tool (like Wireshark or Microsoft Network Monitor) to validate the communication. It is suggested to use the Microsoft Windows "LPR" command line utility (see above in Step 2 for included operating system support of LPQ). This allows you to make a directed communication attempt at a printer rather than wait for a random event. If you see "RST" (reset) packets or "continuation" packets, the network is experiencing delays or is blocking the transmission and will have to be resolved by the site's IT group. This type of problem can often be resolved by placing a Pharos server that hosts both the queue and the Pharos terminal on the same subnet of the print device.
1. Beginning with Revision 94 (Print Services and Administrator) for Uniprint 8.4 and Blueprint 5.1 Service Pack 1.2, we now support printing via TCP port 9100 (also referred to as the "raw port"). Consult the documentation in both of these releases for implementation instructions.