Basic Checklist

Look up the printer in moira. You should be able to do this by logging into Athena, running moira and following the menus.

It might look like this, for example:

  Printer: money              Duplex queue: money2
  Type: PRIVATE    Hardware type: HP4SI      Hardware address: 08000945f94a
  Printer hostname: MONEY-P.MIT.EDU
  Printer log host: URANIA.MIT.EDU
  Spool host: HUSQVARNA.MIT.EDU
  Remote Printer Name: money                                  Banner page: Yes
  Authentication: no  Price/page: 0    Quota Server: [NONE]
  Restrict list: [none]                   LPC ACL: n42-lpc
  Location: w20-021
  Contact: Hardware Hotline, E40, 253-1410
  Last mod by cfox.root@ATHENA.MIT.EDU at 17-jan-2001 13:35:30 with moira.

If you can't find the printer in moira, look under Finding/Getting a printer entry in moira, below.

Does the printer ping on the network?
From Athena, use the hostname of the printer, which you looked up, and ping it. If the Athena machine that you are using is a sun, you'll want to use the -s option to ping. Hit control-c to stop pinging it.
For example:
```
athena% ping money-p
PING money-p.MIT.EDU (18.187.2.59) from 18.18.0.228 : 56(84) bytes of data.
64 bytes from MONEY-P.MIT.EDU (18.187.2.59): icmp_seq=0 ttl=59 time=2.524 msec
64 bytes from MONEY-P.MIT.EDU (18.187.2.59): icmp_seq=1 ttl=59 time=2.453 msec
64 bytes from MONEY-P.MIT.EDU (18.187.2.59): icmp_seq=2 ttl=59 time=2.375 msec

--- money-p.MIT.EDU ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/mdev = 2.375/2.450/2.524/0.083 ms
```
If the printer is not on the network, you need to decide how the printer should have gotten its network configuration.
The printer can and should use bootp if
1. It is a network capable HP printer.
2. It is configured in moira with the correct hardware address. (In the example moira output above, this is Hardware address: 08000945f94a.)
3. It is on a network where bootp packets are forwarded. (This is the case in all except a small number of exceptions; if regular dhcp works there, then bootp should work also.)
If the printer should use bootp, look under Network configuration of bootp printers, below. Otherwise, look under Unsupported network configurations.
Remove (or get help removing) any jobs that are sitting around in the queue, and ask the user to reboot the printer. When you have done so, send a job to the printer yourself. This job may be a test page, from a windows or macintosh that's known to have a correctly configured LPR client. If you're using Athena, a simple way to generate a test job is to use enscript. For example:
```
  echo "This is a test print job" | enscript -Pmoney
```
Then watch the queue by running
```
  lpq -Pprintername
```
from Athena, after you have sent your job.
(Skip to the next step, if your job doesn't print.) How is the user trying to print to the printer? Make sure they are using an lpr client. (If they say "but it works for everyone else but not for me" make sure they aren't the only one not using appletalk.)
Do you see the user's jobs in the queue when you run
```
  lpq -Pprintername
```
If you can print, but the user can't, that indicates a problem at their end. Check all their settings again.
The print servers are set up to try to filter out jobs that aren't printable, but the filters aren't perfect. If the top job lists its status as "stalled" for a long time, that means that as far as the print server can tell, the printer is still working on the job. A misconfigured client might be sending garbage to the printer that is confusing it.
If your job doesn't print, look for a problem with the printer itself. Login to Athena, and
```
  add net-tools
```
(to make hpcheck available to you)
```
  hpcheck -t printerhostname
```
or use -T for a longer version.

If the printer needs physical maintenance (other than being out of supplies) the user should go to hotline@mit.edu.

If there's no obvious problem, then you've done all you can; escalate the problem to bug-print@mit.edu, with the checklist below.

Questions to answer when escalating the problem:

What is the name of the printer?
How is the user trying to print? (if it's appletalk, there's not much we can do)
Has the printer ever worked?
Did you complete the check list above?
What happens when you try to print?

Also include all the relevant case numbers.

If the user has upgraded the printer hardware or wants any of the settings changed, they should fill in the web form again, including a comment if appropriate.

Known problems

Garbage keeps getting printed from the printer, and you don't know who printed it.

We've had a couple of cases where people trying to attack a vulnerability in common printserver software unintentionally sent garbage directly to a printer.
The solution is to make the printer configure itself via bootp, rather than using a configuration that someone entered at the front panel of the printer. This causes the default IP acl to be put in place; see Network configuration of bootp printers.
The printer prints the header sheet in some funny configuration, or duplexes everything sent to it.

It's been known to happen that a job tampers with the persistant configurations. Doing a cold reset should fix the problem; if desired, you can request that the settings be locked down, so that the user can't change them; zephyr for help, or ask bug-print@mit.edu.

More detail

Finding/Getting a printer entry in moira

If there's no entry for this printer, the clients may be only be using appletalk, which doesn't require an IP address. Another possibility is that they've got an IP address for the printer, and are spooling to it directly, rather than through the print server (this is unsupported).

If the printer should be used for something other than appletalk, they should ask for the printer to be set up, by filling in the form at http://web.mit.edu/is/help/print/. Note that they will need an IP address assigned to the printer, before they fill in the form.

The information in moira gets propagated to the print servers, the hesiod servers and the bootp server every time a DCM runs, which is currently every three hours. A user with a new setup will be instructed to wait until the next DCM before rebooting the printer and expecting it to work.

Network configuration of bootp printers

If the user has manually configured their printer, and should bootp instead, they have two options:

Use the menu and buttons on the front of the printer to select "use bootp".
Perform a cold reset.

When a printer uses bootp to get its address, it sends a broadcast packet which gets forwarded at the router to the dhcp servers, then the ops bootp server. If the server recognizes it, it replies with a message that conveys "this is your address and network information, get the rest of your configurations from here". The printer then proceeds to use tftp to get the rest of its configurations.

The configurations that the printer tftp's include setting a password for modifying configurations remotely, setting where and how the printer should send syslogs, and setting an IP acl, which prevents the user from bypassing the print server, and spooling directly to the printer.

You can check these configs from Athena, which hpcheck in the net-tools locker. The common invocation of it is 'hpcheck -T printerhostname'.

If it appears that the information is incomplete (for example, if the IP acl contains 0.0.0.0), it's likely that network problems interfered with the tftp step. Try rebooting the printer, to make it retry; if the network is especially bad, it may take several tries.

Beware: some printers claim to have been configured via bootp, when they haven't. If rebooting it doesn't give it an IP acl, then it needs to be configured to use bootp, whatever hpcheck says.

Unsupported network configurations

If a printer is incapable of using bootp, it's up to the user to get it on the network. Usually, this involves entering the IP address and network information at the printer's front panel. For help, go to the printer manufacturer's web site, and the instruction manuals that came with the printer. This isn't supported.

Using LPC to remove print jobs

If you have not been trained in using lpc, or you aren't on the lpc access list for that printer, find a full time staff member who can use lpc, or zephyr for help.

If you need a refresher on using lpc, see:

  /mit/ops/doc/lpcguide

and run

  lpc help

Zephyr for help

If you need to find someone to help you remove print jobs from a queue, you can send a zephyr to the zephyr instance "printadm", and you are likely to find someone.

Remember to subscribe before sending (from Athena):

  zctl sub message printadm \*

since unless you are subscribed, you won't see any replies that you get.

To send, run

  zwrite -i printadm

If nobody answers, send mail to ops@mit.edu with the request.

How to do a cold reset

A cold reset restores a printer to factory settings. It should be used with caution, since it will destroy any appletalk settings.

To do a cold reset, find the button that's labelled either "go" or "on-line" to the top left of the panel. Holding down this button, power off the printer, then power it back on again. It's important that you keep holding down the button until you see a message on the panel such as "restoring settings". (The labeling of the buttons and wording of the message vary between different models.)