LPRng-HOWTO: Attaching Your Printer

Next Previous Contents

## 3. Attaching Your Printer

When installing a printer, the first step should be to make sure that the printer is actually working independently of the software. The following section outlines some simple diagnostics that you can use to check printer connectivity.

## 3.1 Network Printers

The most flexible and highest throughput printer interface is via a network (TCP/IP) connection. Most high performance printers have a built in network interface, or you can attach them to a printer server box which provides a network interface. Network print boxes can be obtained from Hewlett Packard ( http://www.hp.com), Lantronix's ( http://www.lantronix.com), and Rose Electronics ( http://www.rosel.com).

The network interface usually supports multiple network printing protocols. The most common are the LPD (RFC1179), Socket API, APPsocket, SMB, and Novell Netware interfaces. LPRng directly supports the LPD (RFC1179) and Socket API interfaces, and you can use the `smbclient` program from the Samba Software Package for the SMB interface. There are no plans to support the Novell Netware interface, given the wide range of alternatives.

### Socket API

The most powerful network connection is via the the Socket API. The most common Socket API, and a de facto standard, is the one used by Hewlett Packard on their JetDirect cards, which allows a TCP/IP connection to port 9100. This is a TCP/IP port on the printer that provides a direct connection to the print engine, similar to a serial or parallel port. This connection is usually full duplex and provides error messages and status information during printing.

The Socket API is extremely simple.

1. The user establishes a connection to port 9100. This connection may be refused if the printer is busy printing a job.
2. Once the connection has been established, the print job is sent over the connection. During this transfer, error messages may be returned over the data link.
3. After sending all the data, the sender should do a half-close of the connection. This tells the printer that no more data will be sent.
4. After finishing printing the job, the printer will close the connection.

You can use the netcat utility by Hobbit `<Hobbit@avian.org>` to test that this interface is available and working. If ellipse.ps is a test file, then: The simplest and easiest way to print a file to a network printer appears

> `

>       nc printer.ip.addr 9100 < file
>     Example:
>       nc 10.0.0.25 9100 < ellipse.ps

> `

### LPD (RFC 1179) Protocol

The second most common network print protocol is the RFC1179 TCP/IP protocol. This is described in detail in later sections of this document, but basically consists of a simple set of command and responses.

1. A connection is made to TCP/IP port 515 on the printer. As for the Socket API, this connection may fail if the printer is busy printing another job or has another network connection open.
2. Once the connection has been established, a print request command is sent to the printer, and if printing is allowed an acknowledgment will be received.
3. The files comprising the print job are sent to the printer.
4. The connection to the printer is closed.

During the job transfer no error information is returned, or other status information. This must be obtained by reconnecting to the printer and sending a print status request. This is a major weakness of the RFC1179 protocol.

When the LPRng software package has been installed, it is easy to check printing by using a command of the form:

> `

>       lpr -Plp@ipaddr -Dnetwork file
>     Example:
>       lpr -Plp@10.0.0.25 -Dnetwork ellipse.ps

> `

The `-Plp@ipaddr` option will cause the `lpr` program to make a direct connection to port 515 and send the print file using the RFC1179 protocol. The `-Dnetwork` debugging option will cause detailed network status to be displayed during this process.

In addition to the `lpr` program, the Perl `cheap_lpr` program can be used. This and other test programs are in the LPRng Distribution `UTILS` directory.

### APPsocket

The APPsocket interface is supported by Tektronix and some other printer vendors. It is similar to the Socket API, with a couple of minor differences.

1. The printer has two ports for network connections: TCP port 9100 for TCP/IP stream connections and UDP port 9101 for UDP packet connections.
2. When a 0 length UDP packet or a UDP packet containing only `CR/LF` is sent to UDP port 9101, the printer will return a packet to the sender containing print status information. This information indicates the printers current status (busy, idle, printing) and any error conditions.
3. To send a job to the printer, a connection to port 9100 is made. This connection will be refused while the printer is busy or has a connection to another host.
4. When the TCP connection is established, the job can be sent over the TCP stream. When all of the job has been transferred, the connection should be shutdown for sending data by the sender, but remain open to receive error messages or other information.
5. An end or job indication in the data stream will also act to terminate the connection. This means that if the PostScript CTRL-D (end of job) character is sent in a job, then the connection will be terminated.
6. Once all the data has been received and the job has finished printing, the connection will be terminated by the printer.

The LPRng IFHP filter program has support for the APPsocket interface. Also, there are Perl or other programs which can communicate with the printer. See Tektronix P450 and Family for details.

## 3.2 Network Print Server Boxes

A ``network print server'' is usually a box (external model) or card in a printer (internal model) which has a network connection to a TCP network and software to implement a LPD print server. If it is an external model, The parallel or serial port of the printer is connected to the box, and the print server may support multiple printers. If it is an internal model, the server is usually nothing more than a Network Interface Controller and a ROM containing software that the microprocessor in the printer uses.

The print server may support multiple printing protocols, such as RFC1179 (TCP/IP printing using the LPD print protocol), Novell Printer Protocols, SMB print protocols, and AppleTalk protocols. One of the observed problems with Network Print servers is that while they can usually support one protocol and one user at a time quite well, when you try to use multiple protocols and/or multiple users try to transfer print jobs to the printer, the printer may behave in a very odd manner. Usually this results in a printer failing to finish a job currently being printed, and unable to accept new jobs.

Several of the newer models of print servers have Simple Network Management Protocol (SNMP) agents built into them, and can provide detailed information about their internal functions. By using a SNMP manager such as SunNetmanage or HP-Openview, you can monitor your network printers activities.

I recommend that you use only a single protocol to send jobs to the printer. If you can, I also recommend that you use a print spooler and have only a single host system send a job to the printer.

My best advice on connecting to network printers is not to use the the built-in LPD server, but to use the direct TCP/IP connection to the print engine. Usually this is done to particular TCP/IP port on the printer. For the HP JetDirect and other HP products, this is usually TCP port 9100.

Once you have the direct connection, you can now use various filters to preprocess the print job, insert PJL and PCL commands, or convert text to PostScript or PCL for better print quality.

## 3.3 Parallel Printers

In most UNIX systems the printer port has the name `/dev/lpt`, `/dev/prn`, or something similar. On most systems the `dmesg` utility will print a list of IO devices found during system configuration. Use the following commands to get the information and scan for the device. You should also make sure that the printer device is available.

> `

>     dmesg >/tmp/a
>     grep lp /tmp/a
>     ls /dev/lp*

> `

Gordon Haverland `<haverlan@agric.gov.ab.ca`> supplied this little script, that will assist with this:

> `

>     #!/bin/sh
>     #set -v -x              # uncomment for debugging
>     PATH=/bin:/usr/bin
>     printer=
>     for printer in /dev/lp* ;
>     do
>         echo PRINTER TEST to $printer 1>&2
>         for i in 1 2 3 4 5 6 7 8 9;
>         do
>             echo PRINTER $printer $i > $printer;
>         done
>         echo -e \\r\\f > $printer
>     done
>     exit 0;

> `

If your printer is connected to the device name you provided, then you should get a page of something out. If the output suffers from the ``staircase'' effect, you will see the numbers ``marching'' across the page, otherwise the numbers will all be in a single column.

## 3.4 Serial Printers

If your printer is attached by a serial line, then you may need to set the serial line characteristics before sending the job to the printer. Here are a set of guidelines to following when attaching a serial port printer to a serial line.

1. Check to make sure that the line is not enabled for login. Logins are usually managed by the `getty` (BSD) or `ttymon` (Solaris, SystemV). Check your system documentation and make sure that these daemons are not managing the serial line.

2. Check the permissions and ownership of the serial line. For the most easy testing, set the permissions to 0666 (everybody can open for reading and writing). After you have made sure that you can send jobs to the printer, you might want to change the ownership of the serial line to the LPD server and change the permissions to 0600.

3. Make sure that you can print a test file on the printer via the serial port. This may require setting the line characteristics and then sending a file to the printer. You should try to use 8 bit, no parity, with hardware flow control and no special character interpretation, and definitely no LF to CR/LF translation. The problem is that different versions of UNIX systems have different sets of stty(1) commands to do this. The following simple test script can help in this.

> `

>     #!/bin/sh
>     # 9600, no echo, no CR
>     FLAGS= 9600 -raw -parenb cs8 crtscts
>     DEV= /dev/tty01
>     (stty $FLAGS; stty 1>&2; cat $1 ) <$DEV >$DEV

> `

This shows using stty to set the flags, then to print the current settings, and then using cat a file to the output. If you attach a dumb terminal to the serial port, you can even use this script to ensure that input from the device is echoed to the output with the correct speed, parity, etc.

Experience has shown that serially connected printers are the least reliable and lowest speed. Where possible, it is strongly recommended that they be attached to a network print box which will provide a Socket API interface and handle the low level network to serial port protocol conversions.

Next Previous Contents