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
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,
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 ( //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
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 //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 //aplawrence.com/cgi-bin/ta.pl?arg=640258
for that, or simply:
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 //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
With R5, you simply access this through the Scoadmin Printers
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
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 //aplawrence.com/cgi-bin/ta.pl?arg=104997
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 -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 -> 188.8.131.52 -> 184.108.40.206
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
perror("Connect to port <port> on <host>")
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2009-11-07 Tony Lawrence