APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Network Printers

© December 1998 Tony Lawrence

This article has some SCO Unix specific references, but parts of it apply to any Unix and to Linux.

HP JetDirect is probably the most common network printer. However, in heterogeneous environments, it is also common to see lpd type printers, and now and then some stranger creatures pop up. Since any of these may use different methods to print, you can't always use the same tool to configure them. For example, if you have printer XYZ, it probably will NOT work using the HP Network Printing tools. It might work with lpd printing, but then again it might not.

However, all network printers work by accepting data at some TCP/IP port number, so you can use tools like "netcat" (see below) as long as you know what that port number is.

Whatever the type, there are some hurdles you have to get by first. If you can't ping the printer (or the server it is controlled by for an lpd printer), obviously printing isn't going to work either. Don't make the mistake of pinging by IP address: generally, the printing software is going to rely on name resolution, so you should use the name of the printer or server.

Pay attention to the IP address that ping shows. If it's not what you expected, check your name resolution (/etc/hosts or /etc/resolv.conf). Remember that the printer doesn't care what its name is, but your software to get to that printer probably does. Triple check that everything is in agreement: names, addresses, netmask, gateways.

If the address is not on your network (it has to pass through a router), remember that not only do you need a route to get to that network, but the printer or server needs a route to get back to you. See Routing Basics That address may have to be set on the printer itself.

The easiest network printer to configure is one that's already working on another server. If that's another Unix machine, it may already be set up for remote print serving.

Lpd printing does not necessarily mean that you are printing to another computer- many network print servers support lpd directly (though you may have to do something to turn it on).

Even NT and Novell machines can be lpd print servers. Novell's a little trickier ( https://aplawrence.com/cgi-bin/ta.pl?arg=107217), but once it's done once, it gets easier. NT needs the TCP/IP Printing Service installed, and the service needs to be running (you probably want to set it for Automatic in Services). You may also need to add a dword registry key to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LPDSVC\Parameters. Run regedit (just click Start->Run and type "regedit"), and then click down through to parameters. Then add a new dword value called "SimulatePassThrough", and finally modify it so its value is "1". That's it; you don't need to reboot- the change is immediate. This lets the Unix side format the data without NT deciding it knows better what to do with it.

On the SCO side, you need to "mkdev rlp" if it's a 3.2v4.2 or previous release. You have to be careful not to do this twice, because the mkdev script on 4.2 is unintelligent, and will ruin your printing entirely if it is run again. You can check to see if the directory /usr/spool/lpd exists. If it does, remote printing probably was configured. Don't run it twice. If you have done that (or suspect that you have because things are very broken in the printing department), see https://aplawrence.com/cgi-bin/ta.pl?arg=107455

Even if you haven't run it twice, you could have problems, such as nobody but root being able to print. See https://aplawrence.com/cgi-bin/ta.pl?arg=640258 for that, or simply:

                cd /usr/bin
                chmod 6711 lp lpstat cancel
                chown root lp lpstat cancel
                chgrp daemon lp lpstat cancel

When remote printing is configured, you get asked to define a printer. To add new printers after that, use /etc/rlpconf.

These scripts add entries to /etc/printcap. You'll probably need to either modify /etc/printcap to add "mx#0" (see https://aplawrence.com/cgi-bin/ta.pl?arg=640234 ) or fix the /etc/rlpconf script so that it creates the entries correctly to start with.

Once you have a remote printer defined, you have a directory /usr/spool/lpd, and a directory for each printer within that. In those directories you will find "status" files which may help you understand any problems that come up. For example, if you have a printer "Jane" that is printing to the remote printer "BigDog" on "Server", the status file might say "Waiting for Server to come up." If it did, you'd know that either Server is down, doesn't have a printer named BigDog, isn't running lpd, or that you are unable to communicate with it due to other problems.

The R5 side of this is much easier. You can use "scoadmin", or the old 'mkdev lp' syntax to get to the new Printer Manager and add a Remote Printer (note that for HP Network printers, it's 'mkdev hpnp'). Be sure that your spooler name matches the remote name.

HP Network Printers

On older releases (prior to R5), you need to download the HP software to configure this. This is EFS122, and can be obtained from SCO with:


After installing this, you can

cd /usr/lib/hpnp

With R5, you simply access this through the Scoadmin Printers section.

The HP printers need to have an IP address. If you aren't running DNS, be sure to add the name and address of the printer to /etc/hosts.

If you are attaching to an existing printer, it may already have been assigned an IP address. In that case, you do not need to assign one through the BOOTP choice, you simply need to add the peripheral to the spooler.

HP printers work by creating a directory /usr/spool/lp/admins/lp/interfaces/model.orig. That's where the interface script you choose gets put, and the network script (from /usr/lib/hpnp/hpnp.model) runs your output through that before using hpnpf to get it on the network. You can't have any stty commands in your script in model.orig, but anything else you need to control is done there.

Stair stepping for HP printers can be handled by "-n" or "-N" added to the script; see man hpnpf and /Unixart/printing.html#stairs

Don't add it to the "HPNPF=" line; add it in the line(s) that actually uses $HPNPF. For example, you'd change

    if $REALMODEL "$@" | $HPNPF -x $PERIPH 2> $LOG > /dev/null
    if $REALMODEL "$@" | $HPNPF -x $PERIPH -n 2> $LOG > /dev/null

If you need to use one of the multiport HP Jetdirects (two or more parallel ports), see https://aplawrence.com/cgi-bin/ta.pl?arg=104997 and https://aplawrence.com/cgi-bin/ta.pl?arg=105327

There are network printers that use other methods, such as ftp, or perhaps their own proprietary scheme. If it's proprietary, you may have to depend on the manufacturer to have provided software that will let you get at the printer. However, that doesn't mean you can't have control of the output. You can also front-end the network printer with a local printer: /Unixart/printing.html#wrapper Most network printers support lpd protocols, also.

Network print servers are network devices with parallel or serial ports. These let you put non-network printers on the network. HP makes these, so does Linksys and a number of other people. I've reviewed Intel's at Netport Review.

I've had strange questions about those, like "will there be a conflict at two computers send requests at the same time?". Gosh, no: That's the job of the print server in the unit. It should be able to spool jobs or at least tell a sending computer to hold its water while it deals with what is has. I wouldn't expect to have any problem with that and would consider it sub-standard if I did.


If you get complaints about "tcgetattr" failing, it's because you have stty statements in the interface for a network printer or virtual printer pointing at /dev/null. Comment out the stty's and the complaints will go away. Netcat is another way to print to network printers. Jeff also provides a handy list of Print Server Port Numbers.

The netcat program can also help diagnose problems. The folowing was taken from a newsgroup posting by Kevin Smith (the author of netcat):

$ netcat -d 999 -h hp3 -p 9102

debugl = 999
hostname = hp3
port = 9102
Connect to port 9102 on hp3: Connection refused


debugl = 999

    Your debug level.  Anything >= 1 triggers debug messages.
    There are no "levels", just on and off.

hostname = hp3

    Value from -h arg

port = 9102

    Value from -p arg


    Return value of gethostbyname() which is the address of the
    hostent struct which is useless unless it's 0 which means there
    was an error.

    This translates the host name (hp3) into an ip address.


    Return value of the socket() call.  It's really a file descriptor
    for the network connection.  Not too many reasons for this to fail.
    Useless unless it's -1.  Should always be 3 (stdin = 0, stdout = 1,
    stderr = 2, 3 is next).

    This is the first half of opening a network connection.


    The ip address in hex, as found by gethostbyname(), not adjusted
    for network byte order.

    0x2882b8d0 -> 0x28.0x82.0xb8.0xd0 -> ->

    I should be using inet_ntoa() to show the ip.


    The return from the connect() call.  Who knows why this was
    failing for the coff and not the elf versions.  I run a coff
    version on OSR 5.0.0 (compiled on OSR 5.x though).

    This is the second half of opening a network connection, where the
    target host is actually contacted and the connection is established.

Connect to port 9102 on hp3: Connection refused

    Output of

        perror("Connect to port <port> on <host>")

See also

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> A.P. Lawrence, Linux/Unix Consultant-Network Printers

Inexpensive and informative Apple related e-books:

Take Control of Automating Your Mac

Take Control of the Mac Command Line with Terminal, Second Edition

Photos: A Take Control Crash Course

Take control of Apple TV, Second Edition

El Capitan: A Take Control Crash Course

More Articles by © Tony Lawrence

Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

Writing in C or C++ is like running a chain saw with all the safety guards removed. (Bob Gray)

Linux posts

Troubleshooting posts

This post tagged:




Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode