Recommendations to (K)Ubuntu Dapper users: How to restore an uncrippled CUPS [3: network printer discovery with SNMP]

[3] Enabling network printer auto-discovery (with new "snmp" backend of CUPS 1.2)

My last two blog entries explained....

• ...how Ubuntu users can restore the CUPS web interface to full functionality, and
• ...how Ubuntu user can re-enable the client-side printer browsing so they may automatically discover and use printers shared by CUPS servers on the network.

This one will deal with restoring network printer auto-discovery goodness into their CUPS installation.

First have a look at this screenshot. It shows the http://localhost:631/admin/ web interface of a CUPS 1.2.0 server with a successfull network printer discovery. (Do I need to explicitely state, that this discovery will only work if there are actually network printers in your office to be discovered?):

[image:2126 align="center" size="preview" hspace=4 vspace=2 border=0 class="showonplanet"]

Please take good note of this fact: CUPS network printer auto-discovery is something completely different from the CUPS client site printer browsing we discussed last time. To re-iterate again:

• client site printer browsing discovers printqueues that are announced (and usually also shared) by other CUPS servers on the network. These include network-attached (IPP, AppSocket/JetDirect or LPR/LPD-connected) as well as locally connected (with parallel, USB, serial, IrDA, FireWire, or SCSI links) devices which are installed as printqueues on the servers. Printing to queues discovered this way will make your box act as a CUPS print client; jobs will go through the CUPS print server, before arriving at the printing device.
• network printer auto-discovery scans for printing devices that are connected to the LAN with an ethernet cable or a WiFi interface and which respond to the SNMP broadcast query made by CUPS. The produced list will silently leave out any printers that already have a local queue installed. After discovery, an easy to use "Add Printer Wizard" lets users install new print queues with 2 simple mouse clicks. Printing to queues installed this way will make your computer act as its own print server; jobs will go directly to the printing device.

This method of network printer discovery is a completely new feature in CUPS 1.2, enabled by default. Ubuntu Dapper does include CUPS 1.2 -- so Dapper users should already have seen this, no? Let's see:

[image:2127 align="center" size="preview" hspace=4 vspace=2 border=0 class="showonplanet"]

No! The network printer discovery feature was amputated by Ubuntu's packagers. Therefore it will be hardly known to any Ubuntu user. However, they are lucky: it is extremely easy to restore. Just run one command, to get this sweetness up and running:

 sudo ln -s  ../backend-available/snmp /usr/lib/cups/backend/snmp

Let's have a closer look. The page shown in the first screenshot at the top took about 3 seconds to build. (With the snmp backend disabled, it takes less than 1 second). What does it show? In addition to the other new stuff in the /admin part of the web interface it lists a bunch of uninstalled network printers, and offers to install them by clicking on the "Add This Printer"-button.

How did it work?

The new "snmp" backend (usually hosted in /usr/lib/cups/backend/) is run each time you access the /admin page. The snmp backend did perform the following operations to create the list:

• send an SNMPv1 broadcast to the LAN, querying all nodes to ask if they are printers
  (for SNMP-knowledgeable geeks out there: it uses the Host MIB; future releases will also support scanning for vendor-specific SNMP OIDs and the new PWG Port Monitor MIB);
• memorize all nodes' IP addresses which respond;
• individually query each memorized node for their specific protocol capabilities;
• first try if the device supports Internet Printing Protocol (IPP);
• if not successful in getting an IPP response, try AppSocket (a.k.a. "HP JetDirect" or "Direct Network" or "TCP/IP printing");
• if AppSocket fails, try if the node supports LPR/LPD;
• once there is a response, query for the exact "printer make and model" string.

Clicking one of the "Add This Printer"-buttons will yield this page:

[image:2128 align="center" size="preview" hspace=4 vspace=2 border=0 class="showonplanet"]

CUPS has preselected the PPD (that represents the "driver") it thinks is best for the discovered model; but of course, you can override that pre-selection if you want. Confirming the PPD with the "Add Printer"-button, will shortlydisplay a confirmation message first:

[image:2129 align="center" size="preview" hspace=4 vspace=2 border=0 class="showonplanet"]

and then automatically redirect to the page where you can "Set Printer Options":

[image:2130 align="center" size="preview" hspace=4 vspace=2 border=0 class="showonplanet"]

The "Set Printer Options" page is important for various reasons:

• to correctly fill in the "Options Installed" part [the device may or may not have an optional duplexing unit built in, or additional paper trays,...],
• setting the default paper size [Letter or A4],
• other settings may be desired as defaults, such as Duplex printing

One cool feature of this: it even notices if you try to set forbidden combinations of print options, such as "Duplex printing" on "Transparency" media. (This combo wouldn't make much sense, even if it worked -- but more importantly, it does not even work, because it would jam in the "fuser" system of the laser printer and cause damage to it, when the transparency is passing the heat burn-in unit twice within a short time -- hence, the PPD forbids this combination by enumerating it in its "UIConstraints" section):

[image:2131 size="preview" align="center" hspace=4 vspace=2 border=0 class="showonplanet"]

Of course, the snmp backend is not only beneficial for web interface users. You can also run it from the commandline:

  /usr/lib/cups/backend/snmp 2>&1 | tee ~/cups-snmp.log

Or, if you are an Ubuntu user with the snmp backend still disabled, try:

  /usr/lib/cups/backend-available/snmp 2>&1 | tee ~/cups-snmp.log

This will show you the result in the terminal window, and at the same time store it in the ${HOME}/cups-snmp.log file. Each printer discovered on the net, and not yet installed locally will be displayed on a line of tis own, showing this info:

• "Device" "URI" "ID" "make-and-model IP-address" "printer-info"

Example:

 network ipp://10.162.2.92:631/ipp "Ricoh IPP Printer v2.0" "Ricoh IPP Printer v2.0 10.162.2.92" ""
 network socket://10.162.2.93 "infotec  ISC824" "infotec  ISC824 10.162.2.93" ""
 network ipp://10.162.2.94:631/ipp "Canon iR5000-6000" "Canon iR5000-6000 10.162.2.94" ""

SNMPv1 is not exactly famous for its built-in security features. Quite the contrary. It uses something dubbed "community name" for authentication and transfers that in clear text across the wire. By default, 99% SNMP devices are factory-set to use the SNMPv1 community name "public". And for 98% of those, this setting was never changed after the printer was installed. (Most network admins don't bother to read the printer manuals). So "public" is what the CUPS utility also probes by default in order to query the printer.

Of course, responsible network admins in security conscious environments do set a different community name, or do even disable SNMPv1 altogether (and go for SNMPv3 if their printer supports it). However, CUPS currently only supports SNMPv1 with this utility. This is not an additional security risk -- if your printer allows SNMP queries with SNMPv1 it is not CUPS' fault...

So if an admin has set different community names for his devices, he can also tell CUPS about it. He should look into the /etc/cups/snmp.conf; there he can set different community names to use...

If you want to see more output for debugging purposes, try one of these commands:

  CUPS_DEBUG_LEVEL=1 /usr/lib/cups/backend/snmp 2>&1 | tee ~/cups-snmp-l1.log
  CUPS_DEBUG_LEVEL=2 /usr/lib/cups/backend/snmp 2>&1 | tee ~/cups-snmp-l2.log
  CUPS_DEBUG_LEVEL=3 /usr/lib/cups/backend/snmp 2>&1 | tee ~/cups-snmp-l3.log

I really do wonder what the reasoning of the CUPS packagers for Dapper was when they decided to hide the snmp backend from their users and disable it.

I think this decision should be reverted!