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.
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 ./hpnpcfg
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 to if $REALMODEL "$@" | $HPNPF -x $PERIPH -n 2> $LOG > /dev/null
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 gethostbyname()=0x404340 socket()=3 sin.sin_addr.s_addr=0x2882b8d0 connect()=-1 Connect to port 9102 on hp3: Connection refused Explanation: 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 gethostbyname()=0x404340 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. socket()=3 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. sin.sin_addr.s_addr=0x2882b8d0 The ip address in hex, as found by gethostbyname(), not adjusted for network byte order. 0x2882b8d0 -> 0x28.0x82.0xb8.0xd0 -> 220.127.116.11 -> 18.104.22.168 I should be using inet_ntoa() to show the ip. connect()=-1 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>")
Got something to add? Send me email.
More Articles by Tony Lawrence © 2009-11-07 Tony Lawrence