Difference between revisions of "Bering-uClibc 4.x - User Guide - Advanced Topics - Setting Up a Print Server"

Latest revision as of 10:29, 24 April 2011

This material copied from http://leaf.sourceforge.net/doc/bup9100.html with some amendments for Bering-uClibc 4.x
Please report any problems with the content. Davidmbrooke 11:43, 23 April 2011 (UTC)

Objectives

This page explains how to turn a Bering LEAF router into a print server using the p9100.lrp Package. This package provides raw socket printing on TCP 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.

Prerequisites

What you need:

• A working Bering-uClibc 4.x router. It should be configured to a known working state before you go messing with print server configuration.
• Modules for printing and for driving the parallel port(s): lp.ko, parport_pc.ko, parport.ko. These are included in modules.tgz.
• A monitor and keyboard (attempting to do this headless can cause some problems on some motherboards).
• A client machine that you can use to test printing across the network.

Ensure hardware resources are available.

Ensure you can answer the following questions:

• Which printer port(s) do you plan to use?
• Are their IRQs available in the system BIOS?
• Are their IRQs available in Bering? To find out, run the command:

cat /proc/interrupts

and make sure that the IRQs your ports will use are not already in use.

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:

• lp0 (LPT1) is usually set to use IO address 0x378 and IRQ 7. OEM and older motherboards may use 0x3BC.
  • This will be presented on TCP port 9100.
• lp1 (LPT2) is usually set to use IO address 0x278 and IRQ 5.
  • This will be presented on TCP port 9101.
• lp2 (LPT3) setting recommendations seem to vary with your hardware.
  • This will be presented on TCP port 9102.

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.

Configure the system to print

Packages

Load the p9100.lrp Package by adding p9100 to the list of Packages specified in the leaf.cfg file on the boot media. There are no special dependencies for this Package.

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

Modules

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

The "hardware" Modules parport_pc.ko and parport.ko should be loaded automatically at boot time provided they are present in the /lib/modules/ directory, and they can therefore be installed by the "Find & load modules for hardware" option in the LEAF configuration menu.

The remaining Module lp.ko is not a hardware device driver and so needs to be loaded with an explicit entry in /etc/modules. Simply add a line which says:

lp

If this is done before running "Find & load modules for hardware" then file lp.ko will be automatically extracted from modules.tgz and copied to /lib/modules/.

Device files

On Bering-uClibc 3.x and earlier device files like /dev/lp0 were created by scripts such as /var/lib/lrpkg/root/dev.mk. This is no longer the case with Bering-uClibc 4.x; the device files are created automatically when Module "lp" is loaded.

Firewall rules

If Shorewall is running you need to configure the Shorewall rules file to allow incoming print requests on TCP ports 9100 through to 9102 (depending on the number of printers connected).

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

If you only have one printer connected, and therefore only need port 9100, an alternative syntax using Shorewall's "Jetdirect" macro is:

Jetdirect(ACCEPT)      loc     fw

Save and quit the file.

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 and it is not separately configured to use the TCPWrapper library.

Having made all these changes, you need to back up the configuration and restart the system. In the Bering menu, save the configuration.

Test your setup

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:

parport_pc 00:07: activated
parport_pc 00:07: reported by Plug and Play ACPI
parport0: PC-style at 0x378 (0x778), irq 10 [PCSPP(,...)]
lp0: using parport0 (interrupt-driven).

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 lp0 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.

Configuring clients to print

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.

Troubleshooting

(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. 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:

netstat -lt

Look for a line like:

tcp        0      0 :::9100                 :::*                    LISTEN

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 to 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.

Further Information

For more on BIOS parallel port settings:

• The Kernel printer devices chapter in the Printing How-to by Grant Taylor.
  • Reports "page not found" Davidmbrooke 11:43, 23 April 2011 (UTC)
• The Linux 2.4 Parallel Port Subsystem by Tim Waugh.
  • But we're using 2.6 for Buc 4.x Davidmbrooke 11:43, 23 April 2011 (UTC)
• The Linux Parallel Port Sharing (parport) by Tim Waugh.