SDB:Printing via TCP/IP network
This article is for CUPS up to version 2.x under Linux with the traditional filtering system and backends there.
The nowadays driverless printing workflow is rather different.
Terms and Definitions
A special device with a TCP/IP network connection and one or more parallel or USB connections for parallel port or USB printers is called a printserver box.
A printer with a built-in TCP/IP network interface is called a network printer. Basically a network printer has a printserver box built in.
Therefore setup of a network printer and a printserver box is the same.
In contrast to a printserver box a print server machine means a real computer which offers a print service.
The computer where the user submits a job is called the client or more precisely the client machine.
Prerequisites
The printer must be supported by openSUSE, see SDB:Installing a Printer
Other documentation
See the "Reference" manual and in particular since openSUSE 11.1 read the help text in the YaST printer module for the YaST printer setup dialogs 'Print Via Network' and 'Share Printers'.
Network Printer Setup
The connection determines which way data is sent to the printer device. If a wrong connection is used, no data can be sent to the device so that there cannot be any printout.
A connection is specified as so called Device URI, see SDB:CUPS in a Nutshell the section "The Backends". Its first word (the so called URI scheme) specifies the kind of data-transfer, for example 'parallel', 'usb', 'socket', 'lpd', or 'ipp'. After the scheme there are more or less additional parts (separated by slash '/' characters) which specify the details for this kind of data-transfer.
Printserver box and network printer access happens via three different network protocols. See the manual of your network printer or printserver box what your particular device supports:
TCP Port (AppSocket/JetDirect)
The IP address and a port number is needed to access it. Often the port number 9100 is the right one. It is the simplest, fastest, and generally the most reliable protocol. The matching device URI is:
socket://ip-address:port-number
For example a network printer with IP 192.168.100.1 which is accessible via port 9100 may have a device URI like: socket://192.168.100.1:9100
Line Printer Daemon (LPD) Protocol
A LPD runs on the device and provides one or more LPD queues. The IP address and a LPD queue name is needed to access it. Almost all network printers and printserver boxes support it. Often an arbitrary queue name or 'LPT1' works somehow. But using a correct LPD queue which does not somehow change the data or add additional formfeeds or banner pages could be essential for reliable printing. The matching device URI is:
lpd://ip-address/queue
For example a network printer with IP 192.168.100.2 which is accessible via LPD protocol with a remote LPD queue name 'lpt1' may have a device URI like: lpd://192.168.100.2/lpt1
Internet Printing Protocol (IPP)
IPP is the native protocol for CUPS which runs on a real computer but when IPP is implemented in a small printserver box or in a network printer, it is often not implemented properly. Only use IPP when the vendor actually documents official support for it. The matching device URI is:
ipp://ip-address:port-number/resource
What 'port-number' and 'resource' exactly is depends totally on the particular network printer or printserver box model. For more information have a look at Using Network Printers on openprinting.github.io/cups
In case of problems
Connect the printer device directly via USB and configure the printer as local printer for testing purposed to exclude problems regarding the network.
In case of wireless networking
When printing works via USB but not via wireless network, connect the device via traditional wired network cable and re-do the printer setup to test if printing works via traditional wired network.
In theory it should not matter which kind of network connection is used (wireless versus wired network connection) - provided the particular network connection works reliable. In practice at least for printer devices wireless network connection is known to often not work reliable (compared to traditional wired network connection).
Furthermore wireless networking could be insecure, see SDB:CUPS_and_SANE_Firewall_settings.
Network printer or printserver box does not work reliably
Sometimes problems with the print spooler on a printserver box or a network printer occur, especially if several clients send print jobs to the printserver box or the network printer at the same time. In this case, the print spooler on the printserver box or the network printer may get confused. Because of the fact that this depends on the print spooler in the printserver box or in the network printer, it is almost impossible to solve such problems. In this case it is recommended to connect the printer directly to a real print server machine.
Nevertheless, you can make improvements with the following procedure:
One computer acts as print server for the printserver box or the network printer. All clients send the print jobs to this print server and only this print server manages the spooling of the print jobs and sends them (one at a time) to the printserver box or the network printer.
In the end this is printing via CUPS Server:
Printing via CUPS Server
See SDB:CUPS in a Nutshell in particular the section "Configuring CUPS in the Network".
To access a SMB printer share, the RPM package samba-client must be installed. The package provides the CUPS backend 'smb' which is a link to the /usr/bin/smbspool program which actually sends the data to a SMB printer share. A server name and a printer share name and optionally a workgroup name is needed to access it. Furthermore a user name and a password may be required to get access. A matching full device URI is:
smb://username:password@workgroup/server/printer
For more information have a look at "man smbspool" and see SDB:Printing via SMB (Samba) Share or Windows Share
Printing via Traditional UNIX Server (LPR)
A Line Printer Daemon (LPD) runs on a traditional UNIX server and provides one or more LPD queues. The IP address and a LPD queue name is needed to access it. The matching device URI is:
lpd://ip-address/queue
Printing via Novell Netware Print Server (IPX)
To access print queues on a Novell Netware print server, the RPM package ncpfs must be installed. The ncpfs package existed up to openSUSE 12.1 and it also exists for SUSE Linux Enterprise 11. Accordingly printing via a Novell Netware print server is no longer supported since openSUSE 12.2 and SUSE Linux Enterprise 12. The ncpfs package provides the CUPS backend 'novell' which runs the nprint program which actually sends the data to a Novell Netware print queue. A server name and a printer queue name is needed to access it. Furthermore a user name and a password may be required to get access. The matching device URI is:
novell://username:password@server/queue
For more information have a look at "man nprint" and the other documentation in the RPM package ncpfs.
Testing those connections
The yast2-printer RPM provides test scripts to test whether or not access via a particular kind of connection works.
Have in mind that those scripts implement only basic generic tests so that the test result could be wrong. Nevertheless in case of problems those tests may indicate a trouble spot.
Testing a TCP port connection
To test a TCP port connection run
root@host# /usr/lib/YaST2/bin/test_remote_socket HOST PORT
Replace HOST with the IP address or the host name of the remote host or network printer. Replace PORT with the port number on the remote host or network printer.
An exemplary test_remote_socket script to test a TCP port connection (attention - very long lines could be shown wrapped in your browser):
#! /bin/bash
MY_NAME=${0##*/}
HOST="$1"
[ -z "$HOST" ] && { echo "Usage: $MY_NAME HOST [PORT]" ; exit 1 ; }
PORT="$2"
[ -z "$PORT" ] && PORT=9100
if ( ( echo -n '' >/dev/tcp/$HOST/$PORT ) & PID=$! ; sleep 2 ; kill $PID ; wait $PID )
then if ( ( echo -en '\r' >/dev/tcp/$HOST/$PORT ) & PID=$! ; sleep 2 ; kill $PID ; wait $PID )
then echo "Port $PORT on host $HOST accepts data"
exit 0
fi
echo "Connection possible to port $PORT on host $HOST but does not accept data"
exit 1
fi
echo "No connection possible to port $PORT on host $HOST"
exit 1
For the reasoning behind "... & PID=$! ; sleep 2 ; kill $PID ; wait $PID" see https://fate.opensuse.org/312491
Testing a LPD/LPR connection
To test a LPD/LPR connection run
root@host# /usr/lib/YaST2/bin/test_remote_lpd HOST QUEUE
Replace HOST with the IP address or the host name of the remote host or network printer. Replace QUEUE with the queue name on the remote host or network printer.
An exemplary test_remote_lpd script to test a LPD/LPR connection (attention - very long lines could be shown wrapped in your browser):
#! /bin/bash
MY_NAME=${0##*/}
HOST="$1"
QUEUE="$2"
[ -z "$HOST" -o -z "$QUEUE" ] && { echo "Usage: $MY_NAME HOST QUEUE [TIMEOUT]" ; exit 1 ; }
TIMEOUT="$3"
[ -z "$TIMEOUT" ] && TIMEOUT=10
if ! ( ( echo -n '' >/dev/tcp/$HOST/515 ) & PID=$! ; sleep 2s ; kill $PID ; wait $PID )
then echo "No connection possible to LPD port 515 on host $HOST"
exit 1
fi
echo "Connection possible to LPD port 515 on host $HOST"
export NETCAT=$( type -ap netcat | head -n 1 )
export FUSER=$( type -ap fuser | head -n 1 )
if test -z "$NETCAT" -o -z "$FUSER"
then echo "Cannot test if queue $QUEUE on host $HOST accepts print jobs because"
[ -z "$NETCAT" ] && echo "netcat not executable"
[ -z "$FUSER" ] && echo "fuser not executable"
exit 1
fi
NETCAT_IN=$( mktemp -u /tmp/$MY_NAME.in.XXXXXX )
NETCAT_OUT=$( mktemp -u /tmp/$MY_NAME.out.XXXXXX )
mkfifo $NETCAT_IN
mkfifo $NETCAT_OUT
echo "Testing if queue $QUEUE on host $HOST accepts print jobs:"
PORT=$( for P in 721 722 723 724 725 726 727 728 729 730 731
do $FUSER -n tcp $P &>/dev/null || { echo $P ; break ; }
done )
if test -z "$PORT"
then echo "Failed to test if queue $QUEUE on host $HOST accepts print jobs"
echo "because there is no LPD source port (721..731) available"
exit 1
fi
# "\002$QUEUE\n" is a LPD request to receive a new job for $QUEUE
# The remote lpd sends '\000' if it accepts the request.
# Then we must send "\001\n" back which is a request to cancel the new job.
# As there may be no response from the remote port we have additionally
# a "kill $PID" time bomb which would kill the netcat process after $TIMEOUT.
$NETCAT -w $TIMEOUT -p $PORT $HOST 515 <$NETCAT_IN >$NETCAT_OUT 2>/dev/null &
PID=$!
{ sleep ${TIMEOUT}s ; kill $PID &>/dev/null ; } &
RESULT=""
{ echo -e "\002$QUEUE" ; \
RESULT=$( head --bytes=1 <$NETCAT_OUT | tr '\000' '0' ) ; \
[ "$RESULT" = "0" ] && echo -e "\001" ; } >$NETCAT_IN
rm $NETCAT_IN $NETCAT_OUT
[ "$RESULT" = "0" ] && { echo "Queue $QUEUE on host $HOST accepts print jobs" ; exit 0 ; }
# "\004$QUEUE\n" is a LPD request to receive $QUEUE status in long format.
echo "Queue $QUEUE on host $HOST does not accept print jobs"
echo "Status of the queue $QUEUE (possibly empty or not available):"
echo -e "\004$QUEUE" | $NETCAT -w $TIMEOUT -p $PORT $HOST 515
exit 1
For details about LPD requests see the Line Printer Daemon Protocol in RFC 1179.
Testing an IPP/CUPS connection
To test an IPP/CUPS connection run
root@host# /usr/lib/YaST2/bin/test_remote_ipp HOST QUEUE
Replace HOST with the IP address or the host name of the remote CUPS server. Replace QUEUE with the queue name on the remote CUPS server.
To test a SMB share connection run
root@host# /usr/lib/YaST2/bin/test_remote_smb WORKGROUP HOST SHARE [USER] [PASSWORD]
Replace HOST with the IP address or the host name of the remote SMB server. Replace WORKGROUP and SHARE with the respective values on the remote SMB server and use its NetBIOS host name and if needed provide user and password for authentication.
Test a Novell/IPX connection
To test a Novell/IPX connection run
root@host# /usr/lib/YaST2/bin/test_remote_novell HOST QUEUE
Replace HOST with the IP address or the host name of the remote IPX server. Replace QUEUE with the queue name on the remote IPX server.