This chapter explains how to turn a Bering LEAF router into a print server using Nicholas Fong's p9100.lrp package. The p9100.lrp package provides raw socket printing on port 9100. HP has set port 9100 raw socket printing as a network de facto standard with its JetDirect printers. On Microsoft OS's - from Windows 2000 onwards - this appears as "Standard TCP/IP Port" printing.

You don't need me to tell you that shouldn't run a print server on a router.

Revision History:

Acknowledgements: Nicholas Fong for his Linux Print Server HowTo, for troubleshooting techniques and for making the p9100 package; Brad Fritz for comprehensive troubleshooting techniques; Jacques Nilo for his work creating Bering and Charles Steinkuhler for Dachstein and Eigerstein. Ken Yap for creating the p910nd "tiny, non-spooling printer daemon for Linux hosts" in the first place.

Comments on this section should be addressed to its maintainer: Lee Kimber <lkimber at users.sourceforge.net>>.

What you need:

Ensure hardware resources are available

Ensure you can answer the following questions:

ToDo: does IRQ availability matter where extra ports are running on PCI cards? Also, does it matter in Bering p9100.lrp configurations, given that p9100.lrp seems to use polling instead of interrupt requests? See here for more on polling v interrupts). I have had success with both a motherboard parallel port and an add-on ISA parallel port both using IRQ 7. "Success" in this case means the system handled two print jobs simultaneously.

As a guide: within the BIOS, choose Normal or SPP if possible but EPP is known to work. DMA modes should not be chosen.

Resources available in the BIOS and Bering OS:

Clearly, lp1 - a likely second parallel port - is where IRQ conflicts are likely to occur with routers that have network cards using IRQ5

Also, you may find that add-on parallel port cards force changes to the priority of your printer ports. For example my BIOS puts LPT1 on IO address 0x378 and IRQ 7. The addon 508GE ISA parallel port card I put in itself becomes LPT1 but on IO address 0x3bc. I run both cards on the same IRQ of 7. The add-on card then becomes LPT1 (/dev/lp0) and is printed to via port 9100. The original motherboard parallel port becomes LPT2 (/dev/lp1) and is printed to via port 9101. Your mileage may vary so be prepared to experiment.

Make any changes to hardware that are necessary to avoid IRQ conflicts. Start the Bering system and check that everything is working as it should. If it is, you can move on to configuring printing.

Add the p9100.lrp package to the boot media - floppy/hard disk or CF card.

Call the p9100.lrp package by adding p9100 to the list of packages called in the syslinux.cfg file on the boot media.

Save the file and, if you had mounted the media, unmount it.

Copy the three modules lp.o, parport_pc.o, parport.o to the /lib/modules directory

To make sure the system calls them, add the following entries in /etc/modules

parport
parport_pc
lp

You can get to /etc/modules via the Bering menu by choosing:

Packages Configuration | Modules | Modules

Save the changed file and quit out of the Bering menu. We also need to ensure there are sufficient printer and parallel interfaces for the system to use. From the command line, change directory to:

cd /var/lib/lrpkg

Edit the file root.dev.mk by issuing

ae root.dev.mk

Check the file for the following lines:

(...)
mknod lp0 c 6 0 >null  2>&1
(...)
mknod par0  c 6 0 >null 2>&1

In the stock Bering 1.1 distro, you are likely to find lines setting up two lp nodes. Make sure you add the lines required to set up the "par" nodes.

If you need nodes for more than one printer and parallel port, add more nodes, incrementing the nodes as show below:

mknod lp1 c 6 1 >null  2>&1
mknod lp2 c 6 2 >null  2>&1

mknod par1  c 6 1 >null 2>&1
mknod par2  c 6 2 >null 2>&1

Save and quit the root.dev.mk file.

Set the appropriate permissions on these nodes by editing the root.dev.mod file, which is in the same /var/lib/lrpkg directory.

To this file, add the following:

chmod 666  lp*  >null 2>&1
chmod 640 par* >null 2>&1

Save and quit the root.dev.mod file.

Set security to allow printing from remote machines You need to configure the Shorewall rules file to allow incoming print requests on ports 9100 through to 9102

From the Bering menu, select Packages Configuration, Shorewall, Rules

Assuming that you have one local interface in a zone called "loc" representing the internal network, add the following rule:

ACCEPT	loc	fw	tcp	9100:9102

Save and quit the file with CTL+S

You should not need to allow access to ports 9100 to 9102 in /etc/hosts.allow because the version of p9100 compiled in the p9100.lrp package is not under TCPWrapper control. That is to say, p9100 runs in daemon mode, not from inetd/inetd.conf.

Having made all these changes, you need to back up the configuration and restart the system. In the Bering menu, backup all packages (unless you want to try to figure out which packages are affected by the changes you made).

You can start initial testing when you reboot the machine after making the above changes.

As the system boots, you should look to see that it has loaded the two parport modules and the lp module and that the parport modules successfully bound to the parallel ports.

Evidence that the system loaded the modules correctly includes lines similar to:

parport0 PC-style at 0x378
parport0 irq7 detected
lp0 using parport0 (polling)
lp0 compatibility mode

These do vary a little from system to system so panic only if you see either nothing resembling parallel port messages or if you see distinct failure messages.

The p9100.lrp package runs a script on boot that prints details of the printers it thinks it can print to. You should see these messages in the boot output if p9100.lrp was loaded - though they are no guarantee that the system is working. They look like:

Starting print server LPT1 ready LPT2 ready LPT3 ready

If the boot messages scroll up too quickly to read, you can use SHIFT+PAGE UP before you log in to the system to review it. Or you can log in, quit out of the Bering lrcfg menu and, at the command line, issue:

dmesg | less

to scroll through the boot messages.

Assuming that all looks well after boot, and that you have logged in, and check that the printer service is running by quitting lrcfg to get to the command line and issuing:

ps -ef | grep p910

Check that you can stop it and start it by issuing

svi p910nd stop
svi p910nd start

Both commands should complete successfully. If not, move to the Troubleshooting section below.

There is no way to test if the machine can print from itself. You may see suggestions that it can using the command:

echo "test print" >/dev/lp0

But this command is likely to return the message

cannot create /dev/lp0: error 16

even on a machine that is known to be printing successfully when the print request is made from a remote client. To properly test the machine you need to print to it from a networked client.

Nicholas Fong maintains an excellent Linux print server how-to that includes detailed instructions on configuring different client operating systems to print to raw socket printers.

Having set up the client, try to print to the server. If you get no print out, it's time to start troubleshooting.

Note that the second Standard TCP/IP printer you configure on a Microsoft 2000/XP may refuse to accept the printer port name and IP address that you specify (because they duplicate the first printer). Just give it a dummy name and continue. Go back after you are finished and change the IP address and port name to whatever values you want to give them. Make sure that you set the correct port number for the device you want to print to on the server.

Setting up Red Hat Linux 8 and 9 clients is easy. Presumably other Linux distros are as easy too, though these instructions have only been tested on Red Hat Linux 8 and 9.

Both Red Hat 8 and 9 have printing configuration applications in Gnome's Systems Settings menu. This tool makes printer set-up pretty much the same between the two versions even though Red Hat 8 used lpd as its default printing system while Red Hat 9 uses CUPS.

From the printing configuration tool, use the "Add" button to start the wizard that guides you through the rest of the setup. From there the steps are quite obvious but make sure you have selected JetDirect as the printing type, set the IP address of the Bering server as the printer "Name", and that you have selected the correct printer driver. You may need to experiment with printer drivers before you have success. This is because there may be several drivers available for each printer and because - in Red Hat's case at least - the printing configuration tool seems to need to have changes saved, be closed and reopened and the configuration checked before it truly saves the chosen driver.

(Mostly taken from Brad Fritz's tips to the LEAF mailing list)

First, work your way up the stack, starting with the hardware. Did boot complete successfully with no error messages and with the required hardware and modules being found? If not, the missing or failed element is likely to give you your strongest lead to the problem. A typical example might be signs of an IRQ conflict or that the parport modules report a different IRQ to the one you had previously configured hardware to use.

Nicholas Fong reports that some motherboards will prevent LPT1 from working if there is no monitor attached. He recommends:

Boot up with a monitor attached, after boot up, type ps ax and you should see:

/usr/sbin/p9100d 

Boot up again without attaching the monitor, after boot up, attach a monitor and type ps ax if the /usr/sbin/p9100d disappears, if it does, you have one of those strange motherboards.

There is no cure. You need to change motherboard or add an ISA add-on multi-function IO card with a parallel port.

If you don't see any hardware or boot errors, continue to work up through the stack. Get to the command line and check that the modules are properly loaded by issuing:

lsmod | grep parport
lsmod | grep lp

You should see that the two parallel port modules and the lp module have been loaded.

If they don't, try manually loading them and examining the resources available with and without the modules loaded. Eg:

  # stop printing, remove drivers, and show irq/io state
  svi p910nd stop
  rmmod lp parport_pc parport
  cat /proc/interrupts
  cat /proc/ioports

  # insert drivers specifying irq/io, show irq/io state, start
  # print service, and test printing
  insmod parport
  insmod parport_pc io=0x378 irq=7
  insmod lp
  cat /proc/interrupts
  cat /proc/ioports
  svi p910nd start

Next, check to see if you have parport entries in the /proc filesystem (in other words, the system correctly created the nodes you configured in root.dev.mk and root.dev.mod). Issue:

find /proc/ -name 'parport*'

Verify you have a /dev/lp0 device by issuing:

ls -l /dev/lp*

On a single printer system, the output should look something like:

crw-rw----    1 root     lp         6,   0 Jun 13  2001 /dev/lp0

On a two-printer system, the output should look something like:

crw-rw----    1 root     lp         6,   0 Jun 13  2001 /dev/lp0
crw-rw----    1 root     lp         6,   1 Jun 13  2001 /dev/lp1

Check that the p9100 package did load. The messages you see from issuing:

svi p910nd stop
and
svi p910nd start

should confirm that the package did load.

Check that the p9100.lrp package found all the devices that you expect by issuing:

cat /var/log/syslog | less

and look for signs that the p9100 package found printer devices that you expected and - more likely - failed to find devices that it expected but which are not present. Eg, LPT3 is unlikely On a single printer server you will typically see a message here showing that /dev/lp1 was not configured.

Verify that the daemon is started by issuing:

svi p910nd stop; svi p910nd start
and
ps -ef | grep p910

Verify the daemon is bound to port 9100 (0x238C in hex - not to be confused with the io ports used by the parallel port)

cat /proc/net/tcp | grep -i 238C

The response on a working server looks something like this:

   0: 00000000:238C 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        
0 5791 1 c3d8aa60 300 0 0 2 -1                              

Verify you can connect to that port from a remote client by issuing:

nc 192.168.1.254 9100

or use the printer test files from Nicholas Fong's p9100test.zip file as shown below:

nc 192.168.1.254 9100  <  pcl.prn  (if you have a PCL language printer)
nc 192.168.1.254 9100  < epson.prn  (if you have an Epson printer that uses the ESC/P2
language)
nc  192.168.1.254 9100 < testing.ps  (if you have a postscript printer)

The Windows version of "nc" requires the user to type Ctrl-C when the file is "sent".

If you have a full version of nc (e.g. Linux), replace above by:

nc -q2 192.168.1.254 9100 <  pcl.prn  (if you have a PCL language printer)
nc -q2 192.168.1.254 9100  < epson.prn  (if you have an Epson printer that uses the ESC/P2
language)
nc -q2 192.168.1.254 9100 < testing.ps  (if you have a postscript printer)

ToDo: find out how to interpret the result of this command.

I get no response on my working server - does this mean that no response should mean that everything is OK. What would a "connection refused" message mean?

Run "tail -f /var/log/syslog" on the print server and then verify you can connect to port 9100 from the printing client with:

telnet 192.168.1.254 9100

If there is a problem, expect to see a "connection refused" message. If so, check that the port exists, that Shorewall's rules are letting it through and that the appropriate parallel port exists.

You should see syslog show a message like:

Apr 12 01:50:53 firewall p9100d: Connection from 192.168.2.1 port 1067

This is the p9100 package reporting a connection on its port 9100.

If you see this message, then while you are running tail on /var/log/syslog, try to print to the device from the remote client as you normally would. You should see the same message appear again.

Client-side

Check that your client Standard TCP/IP printing port is connecting to the correct IP address and port number.

9100 prints to /dev/lp0
9101 prints to /dev/lp1
9102 prints to /dev/lp2

Troubleshooting tips that don't seem work

Although it would be handy to test the print server by printing from its own command line, this will likely not work:

Try this from the print server:

echo -en "Hello\f" >/dev/lp0

If you see activity on the printer then that's good. But if you don't seen any activity then that is not necessarily bad. The only effective way to test the print server is to print to it from a remote client.

For more on BIOS parallel port settings: